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

[Michael Elizabeth Chastain <chastain at cygnus dot com>]

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.

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?

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

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.

Michael