From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1554 invoked by alias); 20 May 2011 00:24:39 -0000 Received: (qmail 1530 invoked by uid 22791); 20 May 2011 00:24:37 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SARE_SUB_PCT_LETTER,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 May 2011 00:24:23 +0000 Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p4K0OLYA023034 for ; Thu, 19 May 2011 17:24:21 -0700 Received: from pvc12 (pvc12.prod.google.com [10.241.209.140]) by kpbe14.cbf.corp.google.com with ESMTP id p4K0OJRQ022029 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 19 May 2011 17:24:20 -0700 Received: by pvc12 with SMTP id 12so1514034pvc.28 for ; Thu, 19 May 2011 17:24:19 -0700 (PDT) Received: by 10.68.30.73 with SMTP id q9mr5196479pbh.431.1305851059202; Thu, 19 May 2011 17:24:19 -0700 (PDT) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id h7sm2078920pbg.74.2011.05.19.17.24.17 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 17:24:18 -0700 (PDT) From: Ian Lance Taylor To: binutils@sourceware.org Subject: Re: ld error message %C format References: <20110518154757.GQ20800@bubble.grove.modra.org> <20110520000025.GS20800@bubble.grove.modra.org> Date: Fri, 20 May 2011 00:24:00 -0000 In-Reply-To: <20110520000025.GS20800@bubble.grove.modra.org> (Alan Modra's message of "Fri, 20 May 2011 09:30:25 +0930") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00291.txt.bz2 Alan Modra writes: > On Wed, May 18, 2011 at 04:59:07PM -0700, Ian Lance Taylor wrote: >> Alan Modra writes: >> >> > How do people feel about extending typical linker error messages like >> > the following >> > tmpdir/dump0.o: In function `foo': >> > ./compressed1.c:13: undefined reference to `bar' >> > to always include the section and offset information? >> > tmpdir/dump0.o: In function `foo': >> > ./compressed1.c:13:(.text+0x8): undefined reference to `bar' >> > >> > When debugging toolchain problems, the section and offset is often >> > more useful than the source information. I've checked that this >> > change doesn't seem to break emacs parsing of error messages. >> >> While I'm generally not happy about adding options, I think this is a >> case where we should consider it. That is, consider an option >> requesting more verbose information from linker errors. I think that >> for ordinary users of the linker, i.e., 99.9% of linker users, the >> section+offset will be far more confusing than helpful. > > Perhaps I should give some more background as to why I'd like to make > this change. Current uses of %C are > - multiple definition error > - warning symbol call-back > - undefined symbol error > - reloc overflow/dangerous/unattached errors > - cross reference error > - one use in each of pe.em, pep.em, pe-dll.c > - two uses in each of elf64-ppc.c, elf32-ppc.c, elf32-sh.c > > I'd say that some of these existing uses of %C would benefit from the > extra information, particularly the reloc and cross ref errors. Also, > it's not as if emitting section+offset is entirely new: You get that > for all of these errors if debug info is missing. However, the main > reason I want the section+offset is for replacing uses of > _bfd_error_handler with info->callbacks->einfo in BFD back-end linker > support functions. Some of these already report section+offset. I > don't like to idea of removing information.. > > einfo is attractive for the source function and line info, and %v for > offset doesn't truncate like %lx for 32-bit host, 64-bit target. It's specifically the multiple definition error and the undefined symbol error where I think we should tread carefully. Those are the cases which people will see routinely, and the information about be presented in a way that makes sense and is easy to use for people who know nothing about linkers. I agree that it is somewhat odd to remove information, but I've gotten complaints about verbose linker error messages. And, of course, it's a very common complaint about g++'s error messages. It's hard to know what the right balance is, but I'm pretty sure that presenting all information by default is not it. But I won't continue this conversation farther; you should proceed as you see best. Ian