This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix outputting of debug info for things marked *INTERNAL* (fwd)
- To: Michael Elizabeth Chastain <chastain at cygnus dot com>
- Subject: Re: [PATCH] Fix outputting of debug info for things marked *INTERNAL* (fwd)
- From: Jason Merrill <jason at redhat dot com>
- Date: 19 Feb 2001 14:53:06 +0000
- Cc: dberlin at redhat dot com, gcc-patches at gcc dot gnu dot org
- References: <200102191316.FAA21356@bosch.cygnus.com>
>>>>> "Michael" == Michael Elizabeth Chastain <email@example.com> writes:
> Hi Jason,
> I got out the stabs manual last night and parsed the whole 400-character
> stab. Then I did a bunch of thinking.
> At the moment, there are three constructor methods in the 'T' structure
> declaration: the abstract constructor, the base class constructor, and
> the complete constructor.
Yes. And the latter two are the result of substituting some constants into
> There are also two functions defined in the code: the base class
> constructor and the complete constructor.
>> I think that it probably makes sense to suppress the abstract constructor
>> entirely for non-dwarf debugging backends, since only dwarf has the notion
>> of instances of an inline function.
> Does the abstract constructor have a blob of object code associated with it?
> Does any method or function marked *INTERNAL* have a blob of object code?
Currently, abstract [cd]tors are the only things marked *INTERNAL*. But
again, that's an, er, internal detail that shouldn't be making it into the
debug info. It's not a defined interface by any means.
>> I'm wondering if it makes sense to suppress the in-class mention of one of
>> the concrete constructors as well, so that only one shows up when you do a
> Hoo hah. Daniel Berlin and I had a long discussion about this.
> There are two distinct functions in the object code, and either of them can
> appear on the call stack. In my opinion, they should show up as distinct
> functions in the symbol table. Then the user can disassemble them, take
> their address, breakpoint on either of them, and see the difference when
> they appear on the call stack.
Certainly. But should they both show up in GDB's concept of the type, or
just via demangling symbols we see?
> My favorite names are 'A::A(int)' for a complete constructor and
> 'A::A$base(int)' for a base class constructor.
> I don't know whether I want the base class constructor to appear in the
> ptype. Right now I am inclined to suppress it from the ptype.
What is GDB's representation of structs used for, other than the ptype