From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 973 invoked by alias); 18 May 2011 23:59:31 -0000 Received: (qmail 965 invoked by uid 22791); 18 May 2011 23:59:30 -0000 X-SWARE-Spam-Status: No, hits=-1.8 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) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 May 2011 23:59:14 +0000 Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p4INxDkq014615 for ; Wed, 18 May 2011 16:59:13 -0700 Received: from pvh18 (pvh18.prod.google.com [10.241.210.210]) by kpbe18.cbf.corp.google.com with ESMTP id p4INxB0l004021 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 18 May 2011 16:59:12 -0700 Received: by pvh18 with SMTP id 18so1275535pvh.31 for ; Wed, 18 May 2011 16:59:11 -0700 (PDT) Received: by 10.142.121.41 with SMTP id t41mr1484452wfc.358.1305763151612; Wed, 18 May 2011 16:59:11 -0700 (PDT) Received: from coign.google.com ([67.218.110.18]) by mx.google.com with ESMTPS id s39sm1798463wfc.16.2011.05.18.16.59.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 16:59:11 -0700 (PDT) From: Ian Lance Taylor To: binutils@sourceware.org Subject: Re: ld error message %C format References: <20110518154757.GQ20800@bubble.grove.modra.org> Date: Wed, 18 May 2011 23:59:00 -0000 In-Reply-To: <20110518154757.GQ20800@bubble.grove.modra.org> (Alan Modra's message of "Thu, 19 May 2011 01:17:57 +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/msg00276.txt.bz2 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. Ian