From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31061 invoked by alias); 1 Sep 2009 23:18:05 -0000 Received: (qmail 31048 invoked by uid 22791); 1 Sep 2009 23:18:04 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_84 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 23:18:00 +0000 Received: (qmail 2585 invoked from network); 1 Sep 2009 16:17:57 -0700 Received: from 209-128-106-254.bayarea.net (HELO redwood.eagercon.com) (209.128.106.254) by shell4.bayarea.net with SMTP; 1 Sep 2009 16:17:57 -0700 Message-ID: <4A9DABA4.3010402@eagercon.com> Date: Tue, 01 Sep 2009 23:18:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Keith Seitz , Daniel Jacobowitz , gdb-patches@sourceware.org Subject: Re: [RFA] dwarf2_physname References: <4A9C358E.2050904@redhat.com> <4A9C54F6.1000909@eagercon.com> <4A9C5A66.7060609@redhat.com> <20090901221122.GA24658@caradoc.them.org> In-Reply-To: <20090901221122.GA24658@caradoc.them.org> 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/msg00039.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Aug 31, 2009 at 04:19:02PM -0700, Keith Seitz wrote: >> On 08/31/2009 03:55 PM, Michael Eager wrote: >> >>> Does this mean that (eventually) the DW_AT_MIPS_linkage_name attribute >>> will not be needed by GDB? >> That is exactly what it is intended to do. MIPS_linkage_name is not >> needed in any case I've been able to invent on my >> archer-keiths-expr-cumulative branch, and that branch has MUCH >> tougher C++ tests than FSF gdb does. > > I assume this patch is a distant descendant of the one I sent you a > while back. Is its goal to create a useful name for each symbol, or > to match the one produced by some other source - probably the > demangler? What sort of template cases have you looked at? I'd be concerned about trying to embed name mangling into gdb. Not all compilers (or versions) use the same scheme. > As you know, I spent several some time trying to do without > DW_AT_MIPS_linkage_name. My main goals were cleanliness and > compatibility with a non-GCC compiler (ARM RealView). I came across a > lot of cases where the output from neither GCC nor any other compiler > I could get my hands on made sense without a linkage name in the debug > info - and I couldn't find a way to get sensible representation in > DWARF, either. > > Here's one case I remember having trouble with. > > template int f() > { > return S[0]; > } > > char Foo[3]; > char Bar[3]; > > int main() > { > return f() + f(); > } > > 0000000000000000 W int f<&Bar>() > 0000000000000000 W int f<&Foo>() > > <1><31>: Abbrev Number: 2 (DW_TAG_subprogram) > <32> DW_AT_external : 1 > <33> DW_AT_name : (indirect string, offset: 0x47): f<((char*)(& Foo))> > <37> DW_AT_decl_file : 1 > <38> DW_AT_decl_line : 1 > <39> DW_AT_MIPS_linkage_name: (indirect string, offset: 0x1f): _Z1fIXadL_Z3FooEEEiv > <3d> DW_AT_type : <0x55> > <41> DW_AT_low_pc : 0x0 > <49> DW_AT_high_pc : 0x10 > <51> DW_AT_frame_base : 0x0 (location list) > > You have to represent the name "Foo" in the debug info - the address > isn't enough, there could be other symbols apparently at the same > address. The name this older GCC emits is not useful. Most other > compilers just punted. While hopefully Dodji has made HEAD GCC do > something sensible now, we have to handle all those field compilers :-) I think that this is a problem with how the template instantiation is described. From DWARF 3, Sec. 3.3.7: 1. Each formal parameterized type declaration appearing in the template definition is represented by a debugging information entry with the tag DW_TAG_template_type_parameter. Each such entry has a DW_AT_name attribute, whose value is a null-terminated string containing the name of the formal type parameter as it appears in the source program. The template type parameter entry also has a DW_AT_type attribute describing the actual type by which the formal is replaced for this instantiation. All template type parameter entries should appear before the entries describing the instantiated formal parameters to the function. I think that there should be something like DW_TAG_template_value_parameter DW_AT_name : Foo DW_AT_type : as a child of of f. (I'm pretty rusty on how template functions are described, and, unfortunately, the DWARF Standard doesn't have any examples.) My feeling is that in this case, DW_AT_MIPS_linkage_name compensates for the compiler not generating more complete DWARF. If it did generate DW_TAG_template_value_parameter, there would be no need for DW_AT_MIPS_linkage_name. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077