From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12694 invoked by alias); 6 Jan 2004 19:05:07 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 12685 invoked from network); 6 Jan 2004 19:05:06 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 6 Jan 2004 19:05:06 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1AdwVI-0003UE-KM; Tue, 06 Jan 2004 14:04:36 -0500 Date: Tue, 06 Jan 2004 19:05:00 -0000 From: Daniel Jacobowitz To: David Carlton Cc: Michael Elizabeth Chastain , gdb-patches@sources.redhat.com Subject: Re: [rfc/cp] method stub assertions Message-ID: <20040106190436.GB9422@nevyn.them.org> Mail-Followup-To: David Carlton , Michael Elizabeth Chastain , gdb-patches@sources.redhat.com References: <20040106042841.584854B35A@berman.michael-chastain.com> <20040106170522.GA29597@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2004-01/txt/msg00146.txt.bz2 On Tue, Jan 06, 2004 at 10:41:51AM -0800, David Carlton wrote: > On Tue, 6 Jan 2004 12:05:23 -0500, Daniel Jacobowitz said: > > > The debug information for A::bad6 does not specify that it is a > > method. Rather only the debug info for class A specifies that it > > has a method named A::bad6. > That DW_AT_specification in the definition of C::foo refers to DIE > 0x76, which is the declaration for C::foo. And the declaration for > C::foo is nested within the die for C. So if we're reading the > definition for C::foo, it wouldn't be hard at all to find out that the > DW_TAG_subprogram in question is in fact a method of a class instead > of a free function: follow the specification, and look at its parent > DIE. (It would have been hard a few months ago, but it's not hard > now. :-) ) Right, I wasn't clear. I was referring to the fact that we parse two different DIEs for A::bad6, the one which is a member and the other which is a function - they're both DW_TAG_subprogram DIEs, but one of them is in the class and the other isn't. It doesn't have to be that way, but always is, for GCC. We can and probably should follow the specification to verify that we are in a class. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer