From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26422 invoked by alias); 22 Feb 2012 16:40:45 -0000 Received: (qmail 26122 invoked by uid 22791); 22 Feb 2012 16:40:43 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Feb 2012 16:40:09 +0000 Received: by vcbf13 with SMTP id f13so218763vcb.0 for ; Wed, 22 Feb 2012 08:40:08 -0800 (PST) Received-SPF: pass (google.com: domain of dje@google.com designates 10.220.108.70 as permitted sender) client-ip=10.220.108.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dje@google.com designates 10.220.108.70 as permitted sender) smtp.mail=dje@google.com; dkim=pass header.i=dje@google.com Received: from mr.google.com ([10.220.108.70]) by 10.220.108.70 with SMTP id e6mr19186653vcp.74.1329928808173 (num_hops = 1); Wed, 22 Feb 2012 08:40:08 -0800 (PST) Received: by 10.220.108.70 with SMTP id e6mr15541543vcp.74.1329928808122; Wed, 22 Feb 2012 08:40:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.108.70 with SMTP id e6mr15541532vcp.74.1329928807993; Wed, 22 Feb 2012 08:40:07 -0800 (PST) Received: by 10.220.21.4 with HTTP; Wed, 22 Feb 2012 08:40:07 -0800 (PST) In-Reply-To: <4F4439B2.70101@eagercon.com> References: <4F4439B2.70101@eagercon.com> Date: Wed, 22 Feb 2012 16:40:00 -0000 Message-ID: Subject: Re: Regression handling linkage vs source name From: Doug Evans To: Michael Eager Cc: gdb@sourceware.org, Jan Kratochvil Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQnuJixekzvlxa9oOa2X67Vtf2hoIhc/MmkjrPQPFzHzi3YazWZ+aFeEBnGFZdV7nAZveKrDFJTT7HO3nNTIF/PekR0NwhukPnjtIKTQ7RTVsGCREJmQttsYVvY9KNpRH/PeI6PH/nPxxLOSlLZsHVQyBevjsA== X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00063.txt.bz2 On Tue, Feb 21, 2012 at 4:41 PM, Michael Eager wrote: > There were changes to dwarf2_physname() around July 1, 2011, which > cause it to return a different value. =A0Arguably, the changes make > the function work better, returning the linkage name for a symbol where > it previously returned the source name. Tangential data point: Outside of dwarf2read.c, gdb generally uses "physname" to mean linkage name. I'm not sure dwarf2_physname ever returned the linkage name (for c/c++). I know there's been some changes in how it computes the source name. > But since the source name > is overwritten by the linkage name in the symbol entry, gdb's > behavior is different, and, IMO, incorrect. Can you elaborate on what you mean by overwritten? [It's not what I see.] > Here is the test case: > > $ cat t.c > extern int foo(void) asm ("xfoo"); > > int foo(void) {} > > int main (void) > { > =A0foo (); > } > > $ gdb-before a.out > ... > (gdb) b foo > Breakpoint 1 at ... > > $ gdb-after a.out > ... > (gdb) b foo > Make breakpoint pending on future shared library load? (y or [n])? n > (gdb) b xfoo > Breakpoint 1 at ... > > > The symbol "foo" is no longer present in gdb symbol table > so trying to use the name specified in the source fails. > Before the change, breakpoint, backtrace, and other commands > display the symbol name as in the source (and in the DWARF DIE). > After the change, the linkage name is displayed instead of the > source name. Even pre-dwarf2_physname gdb's have this problem. Maybe you tried a 7.x variant that I didn't (I think I tried 6.8, 7.0, 7.1, and 7.4 - at the time I didn't have easy access to 7.2,7.3 and didn't want to go to trouble of building them). The problem (or at least one of the problems), as I see it, is that the API for creating symbols is broken. gdb does (or at least can) record both the linkage and source names (it does this for "minsyms", e.g. ELF symbols). But the way to set a symbol's name is via symbol_set_names and it only takes a linkage name (though the dwarf2read.c further compounds the problem by passing it the source name - or more accurately the "search" name). symbol_set_names then tries to demangle the name and will record that name as well if the demangling succeeds. > Before the change, dwarf2_physname() calls dwarf2_compute_name() > which returns the symbol name if the language is not C++, Java, > or Fortran, even if the DIE has a DW_AT_linkage_name attribute. > After the change, dwarf2_physname() returns the DW_AT_linkage_name. > > Since gdb doesn't keep both the source name and the linkage > name in the symbol table (a design flaw, IMO) what is the > right way to get the previous behavior, where gdb recognizes > the symbol names from the source file? We need to have dwarf2read.c store both names (linkage name and dwarf name). [More changes may be required beyond that, but I think that's a start.] Your test program shows that we can't assume we can simply demangle the linkage name to get the source name.