From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14786 invoked by alias); 2 Sep 2009 01:12:08 -0000 Received: (qmail 14777 invoked by uid 22791); 2 Sep 2009 01:12:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_83 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; Wed, 02 Sep 2009 01:12:02 +0000 Received: (qmail 17563 invoked from network); 1 Sep 2009 18:12:00 -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 18:12:00 -0700 Message-ID: <4A9DC65F.8020102@eagercon.com> Date: Wed, 02 Sep 2009 01:12:00 -0000 From: Michael Eager User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Daniel Jacobowitz , Keith Seitz , 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> <4A9DABA4.3010402@eagercon.com> <20090901233733.GA32355@caradoc.them.org> In-Reply-To: <20090901233733.GA32355@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/msg00047.txt.bz2 Daniel Jacobowitz wrote: > On Tue, Sep 01, 2009 at 04:17:56PM -0700, Michael Eager wrote: >> I think that this is a problem with how the template instantiation is >> described. > > For your example DWARF: > >> 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 believe DW_AT_name would be S here and not Foo - the name by which > the argument is known inside the instantiation. It's representing Foo > that's a problem; it has to go in the DW_AT_const_value attribute. Yeah. I was trying to figure out whether it was the formal or actual parameter. I wanted "Foo" to appear somewhere. I'm not sure DW_AT_const_value is really appropriate either. > Here's a trickier example: > > template int f() > { > return S[0]; > } > > template struct S {}; > > template int g(S*) > { > return 0; > } > > char Foo[3]; > char Bar[3]; > > int main() > { > return f() + f() + g<5, Foo>(0); > } > > 0000000000000000 W _Z1gILi5EXadL_Z3FooEEEiP1SIXplplT_Li1EszT0_EE > 0000000000000000 W int g<5, &Foo>(S<((5)+(1))+(sizeof (&Foo))>*) > > A patch that can't handle this may still be an improvement - but I'd > like to know how we're approaching this problem, and whether (A) the > lack of compilers generating adequate data, and (B) to the best of my > knowledge, the lack of DWARF constructs for such expressions, is > going to interfere with debugging of heavily templated programs. The DWARF Committee had some discussions about how templates are described in DWARF. Only the instantiations are described, not the declaration. DWARF tries (and sometimes succeeds) in providing enough info for the instantiation that a debugger can infer either the template declaration or how it was instantiated. This breaks down in several areas. There was brief discussion about replacing the current description of templates. The existing scheme was developed in the early 90's with little real-world experience. C++ has evolved significantly since then. On the other hand, I'd be concerned that we would come up with a new description which requires a significant effort to implement and that neither compiler writers nor debugger developers want to adopt it. Sort of like the resistance to the transition from DWARF 1 to DWARF 2. In any case, changes in template descriptions will not be considered for DWARF 4, but possibly for DWARF 5. Suggestions always welcome. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077