From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23978 invoked by alias); 20 May 2011 00:00:54 -0000 Received: (qmail 23968 invoked by uid 22791); 20 May 2011 00:00:53 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SARE_SUB_PCT_LETTER X-Spam-Check-By: sourceware.org Received: from mail-pw0-f41.google.com (HELO mail-pw0-f41.google.com) (209.85.160.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 May 2011 00:00:37 +0000 Received: by pwi12 with SMTP id 12so2012874pwi.0 for ; Thu, 19 May 2011 17:00:37 -0700 (PDT) Received: by 10.68.33.136 with SMTP id r8mr2052992pbi.482.1305849637070; Thu, 19 May 2011 17:00:37 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id t9sm2071150pbo.3.2011.05.19.17.00.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 19 May 2011 17:00:35 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 5FF8E16DE443; Fri, 20 May 2011 09:30:25 +0930 (CST) Date: Fri, 20 May 2011 00:00:00 -0000 From: Alan Modra To: Ian Lance Taylor Cc: binutils@sourceware.org Subject: Re: ld error message %C format Message-ID: <20110520000025.GS20800@bubble.grove.modra.org> Mail-Followup-To: Ian Lance Taylor , binutils@sourceware.org References: <20110518154757.GQ20800@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00289.txt.bz2 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. -- Alan Modra Australia Development Lab, IBM