This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reducing debug info for C++ ctors/dtors
- From: Daniel Jacobowitz <drow at false dot org>
- To: Devang Patel <dpatel at apple dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 11 Jul 2005 20:56:36 -0400
- Subject: Re: Reducing debug info for C++ ctors/dtors
- References: <CCB5AA6D-58F6-4969-A811-152947C10D63@apple.com>
On Mon, Jul 11, 2005 at 05:37:32PM -0700, Devang Patel wrote:
> will emit a class definition LSYM of
>
> .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;__base_ctor ::(0,42)=#
> (0,41),(0,36),(0,43)=*(0,41),(0,9),(0,36);:_ZN5Base1C2Ei;
> 2A.;__comp_ctor ::(0,42):_ZN5Base1C1Ei;2A.;getx::(0,44)=#(0,41),(0,9),
> (0,43),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0
>
>
> However, it is good enough to have
>
> .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41),
> (0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0
>
> and keep the stabs for the cdtors in other contexts, most obviously
> the FUN stab where the function is defined. e.g.
Eh, no. You have just lost any information about what constructors
were declared in the class. Reconstructing this from what constructors
we can find a definition of will be messy and error-prone, because the
debugger will not be able to link a member function back to a
particular member in the definition of the class type.
Dwarf handles clones very differently from stabs. The abstract
definition goes in the class type and the clones only have concrete
instances. That is probably what you want for stabs: have one of the
base/complete ctors, but not both.
The effect on dwarf output might be more interesting.
GDB just ignores all but one of each set in stabs anyway.
--
Daniel Jacobowitz
CodeSourcery, LLC