This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfc/cp] method stub assertions


On Tue, Jan 06, 2004 at 10:41:51AM -0800, David Carlton wrote:
> On Tue, 6 Jan 2004 12:05:23 -0500, Daniel Jacobowitz <drow@mvista.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]