Reducing debug info for C++ ctors/dtors

Reducing debug info for C++ ctors/dtors

[Devang Patel]

Our analysis suggests that reducing certain stabs info for C++ ctors/ 
dtors can lead to significant final size reduction without noticeable  
change in quality of debugging (in STABS world, at least).

For example,

class Base1 {
   public: int x;
   Base1(int i) { x = i; }
   int getx (void) { return x; }
};
int main () {
   Base1 myobj(5);
   return myobj.getx();
}

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.

__ZN5Base1C1Ei:
         .stabd  46,0,0
         .stabd  68,0,3
LFB4:
         stmw r30,-8(r1)
[...]
         lmw r30,-8(r1)
         blr
LFE4:
         .stabs  "_ZN5Base1C1Ei:F(0,36)",36,0,3,__ZN5Base1C1Ei
         .stabs  "this:p(0,45)=k(0,43)",160,0,3,72
         .stabs  "i:p(0,9)",160,0,3,76
Lscope0:
         .stabs  "",36,0,0,Lscope0-__ZN5Base1C1Ei
         .stabd  78,0,0


Our GDB folks are still analyzing compiler output with included  
patch. Initial response is - it looks good.  I'd like to get your  
feedback on this. Is it a good idea in general for other debugging  
formats also ?

If peopler thinks this is a good idea then I can prepare patch for  
mainline.  Do we need a switch to control this ? I do not know. If  
you can think of better name for this switch, feel free to suggest.

-
Devang

[ I am intentionally including this patch to make it easier to read.  
This patch is against apple-local branch so it may not apply cleanly  
to FSF mainline. As I said, if this looks good then I'll prepare  
actual patch. ]

Index: c-common.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.c,v
retrieving revision 1.604.2.12
diff -Idpatel.pbxuser -c -3 -p -r1.604.2.12 c-common.c
*** c-common.c  15 Jun 2005 16:18:32 -0000      1.604.2.12
--- c-common.c  11 Jul 2005 21:34:24 -0000
*************** int flag_access_control = 1;
*** 454,459 ****
--- 454,463 ----

   int flag_check_new;

+ /* APPLE LOCAL begin 4167759 */
+ /* Nonzero if we want to omit debug info for certain constructors and
+    destructors.  */
+ int flag_compact_debug_info;
   /* Nonzero if we want the new ISO rules for pushing a new scope  
for `for'
      initialization variables.
      0: Old rules, set by -fno-for-scope.
Index: c-common.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-common.h,v
retrieving revision 1.276.6.9
diff -Idpatel.pbxuser -c -3 -p -r1.276.6.9 c-common.h
*** c-common.h  23 Jun 2005 01:30:09 -0000      1.276.6.9
--- c-common.h  11 Jul 2005 21:34:24 -0000
*************** extern int flag_access_control;
*** 579,584 ****
--- 579,589 ----

   extern int flag_check_new;

+ /* APPLE LOCAL begin 4167759 */
+ /* Nonzero if we want to omit debug info for certain constructors and
+    destructors.  */
+ extern int flag_compact_debug_info;
+ /* APPLE LOCAL end 4167759 */
   /* Nonzero if we want the new ISO rules for pushing a new scope  
for `for'
      initialization variables.
      0: Old rules, set by -fno-for-scope.
Index: c-opts.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-opts.c,v
retrieving revision 1.135.6.8
diff -Idpatel.pbxuser -c -3 -p -r1.135.6.8 c-opts.c
*** c-opts.c    1 Jul 2005 00:01:07 -0000       1.135.6.8
--- c-opts.c    11 Jul 2005 21:34:24 -0000
*************** c_common_handle_option (size_t scode, co
*** 688,693 ****
--- 688,698 ----
         flag_check_new = value;
         break;

+       /* APPLE LOCAL begin 4167759 */
+     case OPT_fcompact_debug_info:
+       flag_compact_debug_info = value;
+       break;
+       /* APPLE LOCAL end 4167759 */
       case OPT_fconserve_space:
         flag_conserve_space = value;
         break;
Index: c.opt
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c.opt,v
retrieving revision 1.34.6.8
diff -Idpatel.pbxuser -c -3 -p -r1.34.6.8 c.opt
*** c.opt       1 Jul 2005 00:01:08 -0000       1.34.6.8
--- c.opt       11 Jul 2005 21:34:24 -0000
*************** fcheck-new
*** 572,577 ****
--- 572,583 ----
   C++ ObjC++
   Check the return value of new

+ ; APPLE LOCAL begin 4167759
+ fcompact-debug-info
+ C ObjC C++ ObjC++
+ Avoid verbose debug info related to constructors and destructors
+ ; APPLE LOCAL end 4167759
+
   ; APPLE LOCAL begin structor decloning
   fclone-structors
   C++ ObjC++
Index: cp/class.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/class.c,v
retrieving revision 1.705.2.4
diff -Idpatel.pbxuser -c -3 -p -r1.705.2.4 class.c
*** cp/class.c  10 Jun 2005 18:46:07 -0000      1.705.2.4
--- cp/class.c  11 Jul 2005 21:34:25 -0000
*************** build_clone (tree fn, tree name)
*** 3768,3773 ****
--- 3768,3785 ----
         DECL_VINDEX (clone) = NULL_TREE;
       }

+   /* APPLE LOCAL begin 4167759 */
+   if (flag_compact_debug_info)
+     {
+       if (name == base_ctor_identifier
+         || name == complete_ctor_identifier
+         || name == complete_dtor_identifier
+         || name == base_dtor_identifier
+         || name == deleting_dtor_identifier)
+       DECL_IGNORED_P (clone) = 1;
+     }
+   /* APPLE LOCAL end 4167759 */
+
     /* If there was an in-charge parameter, drop it from the function
        type.  */
     if (DECL_HAS_IN_CHARGE_PARM_P (clone))
Index: cp/semantics.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.460.4.7
diff -Idpatel.pbxuser -c -3 -p -r1.460.4.7 semantics.c
*** cp/semantics.c      10 Jun 2005 18:46:22 -0000      1.460.4.7
--- cp/semantics.c      11 Jul 2005 21:34:26 -0000
*************** expand_body (tree fn)
*** 3015,3020 ****
--- 3015,3026 ----
        generating trees for a function.  */
     gcc_assert (function_depth == 0);

+   /* APPLE LOCAL begin 4167759 */
+   if (DECL_NAME (fn) == complete_ctor_identifier
+       || DECL_NAME (fn) == complete_dtor_identifier)
+     DECL_IGNORED_P (fn) = 0;
+   /* APPLE LOCAL end 4167759 */
+
     tree_rest_of_compilation (fn);

     current_function_decl = saved_function;

Re: Reducing debug info for C++ ctors/dtors

[Daniel Jacobowitz]

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

Re: Reducing debug info for C++ ctors/dtors

[Jason Molenda]

On Mon, Jul 11, 2005 at 08:56:36PM -0400, Daniel Jacobowitz wrote:

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

> Eh, no.  You have just lost any information about what constructors
> were declared in the class.  

Yeah, Devang didn't present what we're doing here on the debug side
too well.  We're giving up a bit of information from within gdb --
it won't know what constructors and destructors a class has defined
-- for a large savings in debug info (this can be over 20% of an
application's debug info when lots of templates are in heavy use).

Because the FUN stabs are still present, gdb knows about the
constructors; it can step into them, it can set breakpoints on them.

For most developers, this isn't a worthwhile tradeoff, but for a
certain class of appliations the stabs debug info is enormous and
this helps to ameloriate that by giving up a small bit of gdb
functionality.  This won't be enabled by default even within Apple,
but it is a useful option to have available.


Jason

Re: Reducing debug info for C++ ctors/dtors

[Daniel Jacobowitz]

On Mon, Jul 11, 2005 at 06:11:58PM -0700, Jason Molenda wrote:
> Yeah, Devang didn't present what we're doing here on the debug side
> too well.  We're giving up a bit of information from within gdb --
> it won't know what constructors and destructors a class has defined
> -- for a large savings in debug info (this can be over 20% of an
> application's debug info when lots of templates are in heavy use).
> 
> Because the FUN stabs are still present, gdb knows about the
> constructors; it can step into them, it can set breakpoints on them.
> 
> For most developers, this isn't a worthwhile tradeoff, but for a
> certain class of appliations the stabs debug info is enormous and
> this helps to ameloriate that by giving up a small bit of gdb
> functionality.  This won't be enabled by default even within Apple,
> but it is a useful option to have available.

Thanks for the explanation.  That makes more sense.  Personally, if
you're going to do this, I don't see why you're keeping debug info for
methods; either ditch all artificial methods (including defaulted
constructors but not manually specified constructors), or ditch all
methods.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Reducing debug info for C++ ctors/dtors

[Jason Molenda]

On Mon, Jul 11, 2005 at 09:18:22PM -0400, Daniel Jacobowitz wrote:

> Thanks for the explanation.  That makes more sense.  Personally, if
> you're going to do this, I don't see why you're keeping debug info for
> methods; either ditch all artificial methods (including defaulted
> constructors but not manually specified constructors), or ditch all
> methods.

We considered that too.

On the question of artifical-vs-actual c/dtors, that's one breakdown
I don't have hard numbers on yet, but my argument is that gdb's
knowledge of a class' cdtors is only useful when you're ptype'ing
that class -- you rarely find yourself needing to call the constructor
or destructor on an object from the gdb CLI.  And these things are
awfully long in stabs.  So this is the kind of minor functionality
that the user can be told "turn this switch on and ptype of the
class won't be accurate" and they'll understand the trade-off.

As for ditching methods, this quickly turns into a loss of functionality
because users can no longer call methods on on object from the gdb
command line.  Many users don't know about inferior function calls,
but the Apple debugger UI exposes a feature that sits on top of
those ("custom data formatters"), where you can specify how objects
of a given type should be displayed in the variables window.  For
complex OO types, these are often expressions involving an inferior
function call.

Jason

Re: Reducing debug info for C++ ctors/dtors

[Devang Patel]

On Jul 11, 2005, at 6:18 PM, Daniel Jacobowitz wrote:

> On Mon, Jul 11, 2005 at 06:11:58PM -0700, Jason Molenda wrote:
>
>> Yeah, Devang didn't present what we're doing here on the debug side
>> too well.  We're giving up a bit of information from within gdb --
>> it won't know what constructors and destructors a class has defined
>> -- for a large savings in debug info (this can be over 20% of an
>> application's debug info when lots of templates are in heavy use).
>>
>> Because the FUN stabs are still present, gdb knows about the
>> constructors; it can step into them, it can set breakpoints on them.
>>
>> For most developers, this isn't a worthwhile tradeoff, but for a
>> certain class of appliations the stabs debug info is enormous and
>> this helps to ameloriate that by giving up a small bit of gdb
>> functionality.  This won't be enabled by default even within Apple,
>> but it is a useful option to have available.
>>
>
> Thanks for the explanation.  That makes more sense.

What do others think about this patch? If people think, it is OK
to have one additional knob for users then I'll test and submit
formal patch.

I'll treat silence as, this idea is not OK for FSF GCC. I'd like to
give Jason and our customers compiler with such fix ASAP. And if
it is considered good idea for FSF GCC then I'd like to iron out
small details (e.g. name of switch, stabs specific or general for
all dbg format etc..), in the beginning.


Thanks,
-
Devang

Re: Reducing debug info for C++ ctors/dtors

[Eric Christopher]

> What do others think about this patch? If people think, it is OK
> to have one additional knob for users then I'll test and submit
> formal patch.
> 
> I'll treat silence as, this idea is not OK for FSF GCC. I'd like to
> give Jason and our customers compiler with such fix ASAP. And if
> it is considered good idea for FSF GCC then I'd like to iron out
> small details (e.g. name of switch, stabs specific or general for
> all dbg format etc..), in the beginning.

I think it's useful, probably in the same vein as the
-feliminate-dwarf-dup etc switches. Probably should use the same type of
naming convention too.

-eric

Re: Reducing debug info for C++ ctors/dtors

[Mike Stump]

On Jul 13, 2005, at 11:44 AM, Eric Christopher wrote:
> I think it's useful

To put real life numbers on it, for some, it translates into a  
savings of around 150 megs worth of debug information, and the time  
it takes to compile, assemble and link it.  For linking for example,  
it can take us from being 10x slower to being 7.5x slower than the  
competition, this improve turn-around time when doing edit->compile- 
 >debug...  This is not just a 1% savings, this is a 25% savings.

Would be nice if someone could approve it.

Re: Reducing debug info for C++ ctors/dtors

[Eric Christopher]

> Would be nice if someone could approve it.
> 

It's not in a state that could be approved yet, but hopefully after some
cleanup it will be.

-eric 

Re: Reducing debug info for C++ ctors/dtors

[Mike Stump]

On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote:
>> Would be nice if someone could approve it.
>
> It's not in a state that could be approved yet, but hopefully after  
> some
> cleanup it will be.

Remove the APPLE LOCAL markers, which, is obvious.  Anything else?   
If not, Ok with that change?

Re: Reducing debug info for C++ ctors/dtors

[Eric Christopher]

On Wed, 2005-07-13 at 14:05 -0700, Mike Stump wrote:
> On Jul 13, 2005, at 12:39 PM, Eric Christopher wrote:
> >> Would be nice if someone could approve it.
> >
> > It's not in a state that could be approved yet, but hopefully after  
> > some
> > cleanup it will be.
> 
> Remove the APPLE LOCAL markers, which, is obvious.  Anything else?   
> If not, Ok with that change?

I can't approve it for sure. Comments would be useful, as well as
standardizing on an option name to turn it on. The
-feliminate-stabs-<something> was what I suggested.

-eric