This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: [PATCH] Fix outputting of debug info for things marked *INTERNAL* (fwd)


>>>>> "Michael" == Michael Elizabeth Chastain <chastain@cygnus.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
the first.

> There are also two functions defined in the code: the base class
> constructor and the complete constructor.

Yes.

>> 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?

Never.

> 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
>> ptype.

> 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
output?

Jason


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