From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26759 invoked by alias); 1 Sep 2009 00:06:15 -0000 Received: (qmail 26746 invoked by uid 22791); 1 Sep 2009 00:06:14 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 01 Sep 2009 00:06:09 +0000 Received: (qmail 11583 invoked from network); 31 Aug 2009 17:06:07 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 31 Aug 2009 17:06:06 -0700 Message-ID: <4A9C656D.4050708@eagercon.com> Date: Tue, 01 Sep 2009 00:06:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: tromey@redhat.com CC: Keith Seitz , gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname References: <4A9C358E.2050904@redhat.com> <4A9C54F6.1000909@eagercon.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00000.txt.bz2 Tom Tromey wrote: >>>>>> "Michael" == Michael Eager writes: > > Michael> (http://www.dwarfstd.org/ShowIssue.php?issue=090715.1&type=closed3) > > Michael> There was a significant amount of discussion about whether this was > Michael> really needed. There were a couple examples where it might provide > Michael> information which was not otherwise available or where it compensated > Michael> for linkers which didn't support weak externs. > > I read that page and didn't see these examples. Do you know where we > could find them? They were raised as part of the DWARF Committee discussions: 1) Finding the address of the in-charge constructor when evaluating "new foo()". 2) Look up address of Fortran common block. 3) Demangled to display name of instance of overloaded function. 4) Compensate for compilers which do not generate adequate DWARF. 5) Demangle to find fully qualified name for type. 6) Avoid unresolved external references for symbols which are removed by the linker, if weak externs are not supported. 7) Optimize access with Apple's scheme where DWARF is left in the .o's. Not all of these examples were compelling, nor did it appear that DW_AT_linkage_name was the only means for obtaining the desired information. Some were clearly Quality of Implementation issues, like 4. > It seems to me that if we can do the job without DW_AT_*linkage_name, > then all other things being equal that is what we ought to do, > considering that the new attribute is optional. In practice this only > means that we must determine whether all other things actually are > equal. Almost all attributes in DWARF are optional. Leaving out useful ones only makes it difficult to debug your program. :-( -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077