Making CFLAGS=-g1 bigger but more useful

Making CFLAGS=-g1 bigger but more useful

[Frank Ch. Eigler]

Hi -

I'm working on a little patch that extends the data produced for the
little-used (?)  -g1 mode.  Normally, this produces very little DWARF
data (basically just function declaration locus, PC range, and basic
backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
is very small.

It would be desirable to have an additional level in between -g1 and
-g2, one that also emits just enough data to decode ordinary
functions' parameters at the entry point.  No locals or blocks for
what's inside the function, such as data for inlined functions.  Just
enough to generate call-graphy traces.

The attached patch is a stab in the dim, and eyeballing the results
seems to accomplish the goal (as tested by systemtap gaily tracing
function call graphs with parameters), at the cost of enlarging the
debug data.  For a fedoraish linux kernel (vmlinux), I get these
numbers:

              vmlinux size
stripped        18299708
old-style -g1   23307848  <--
new       -g1   58265716  <--
          -g2   93232955

The stab-in-the-dim -g1 is ten times bigger than the old -g1, but half
the size of -g2.  I am certain that a "stab-in-the-bright" version
should be smaller, if a wise one treaded upon dwarf2out.c more
gingerly than my stomp of a hack.

The basic question though is whether there is interest here for this
sort of -g1.5 mode.  We could ...

- ignore the value of this enlarged -g1 and forget the idea

- adopt the enlarged definition for -g1 and live with the size penalty

- introduce a new -g1.5 (between DINFO_LEVEL_TERSE and DINFO_LEVEL_NORMAL)
  to select the enlarged definition (syntax suggestions wanted)

Suggestions please?


- FChE


diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 69cdb03..eb2116c 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -13437,7 +13437,7 @@ dwarf2out_abstract_function (tree decl)
 
   /* Be sure we've emitted the in-class declaration DIE (if any) first, so
      we don't get confused by DECL_ABSTRACT.  */
-  if (debug_info_level > DINFO_LEVEL_TERSE)
+  if (debug_info_level >= DINFO_LEVEL_TERSE)
     {
       context = decl_class_context (decl);
       if (context)
@@ -13520,7 +13520,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   if (!declaration && !origin && !old_die
       && DECL_CONTEXT (decl) && TYPE_P (DECL_CONTEXT (decl))
       && !class_or_namespace_scope_p (context_die)
-      && debug_info_level > DINFO_LEVEL_TERSE)
+      && debug_info_level >= DINFO_LEVEL_TERSE)
     old_die = force_decl_die (decl);
 
   if (origin != NULL)
@@ -13592,7 +13592,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
        add_AT_flag (subr_die, DW_AT_external, 1);
 
       add_name_and_src_coords_attributes (subr_die, decl);
-      if (debug_info_level > DINFO_LEVEL_TERSE)
+      if (debug_info_level >= DINFO_LEVEL_TERSE)
        {
          add_prototyped_attribute (subr_die, TREE_TYPE (decl));
          add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
@@ -13740,7 +13740,7 @@ gen_subprogram_die (tree decl, dw_die_ref context_die)
   /* In the case where we are describing a mere function declaration, all we
      need to do here (and all we *can* do here) is to describe the *types* of
      its formal parameters.  */
-  if (debug_info_level <= DINFO_LEVEL_TERSE)
+  if (debug_info_level < DINFO_LEVEL_TERSE)
     ;
   else if (declaration)
     gen_formal_types_die (decl, subr_die);

Re: Making CFLAGS=-g1 bigger but more useful

[Andi Kleen]

On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote:
> 
> I'm working on a little patch that extends the data produced for the
> little-used (?)  -g1 mode.  Normally, this produces very little DWARF
> data (basically just function declaration locus, PC range, and basic
> backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
> is very small.

I think what I would like to have is a modus to generate line numbers
(so that objdump -S works nicely) but nothing else. That would be useful
for crash dump analysis etc.

-Andi

Re: Making CFLAGS=-g1 bigger but more useful

[Paolo Bonzini]

> The basic question though is whether there is interest here for this
> sort of -g1.5 mode.  We could ...

Yes, definitely.  I thought about it in two contexts -- regular
debugging, and the fact that the OpenCL GSOC project might require
looking at debug info for memory spaces and types of arguments.

> - ignore the value of this enlarged -g1 and forget the idea
> 
> - adopt the enlarged definition for -g1 and live with the size penalty
> 
> - introduce a new -g1.5 (between DINFO_LEVEL_TERSE and DINFO_LEVEL_NORMAL)
>   to select the enlarged definition (syntax suggestions wanted)

Another possibility, though a much bigger amount of work, would be to
introduce -g options like -f.  The presence of such an option would
imply -g1 or higher, and then you could add -gparameters,
-gline-numbers, -gvar-tracking, -gmacros, etc.

Paolo

Re: Making CFLAGS=-g1 bigger but more useful

[Andi Kleen]

> Another possibility, though a much bigger amount of work, would be to
> introduce -g options like -f.  The presence of such an option would
> imply -g1 or higher, and then you could add -gparameters,
> -gline-numbers, -gvar-tracking, -gmacros, etc.

I would like to have that.
-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Making CFLAGS=-g1 bigger but more useful

[Ian Lance Taylor]

Andi Kleen <andi@firstfloor.org> writes:

> On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote:
>> 
>> I'm working on a little patch that extends the data produced for the
>> little-used (?)  -g1 mode.  Normally, this produces very little DWARF
>> data (basically just function declaration locus, PC range, and basic
>> backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
>> is very small.
>
> I think what I would like to have is a modus to generate line numbers
> (so that objdump -S works nicely) but nothing else. That would be useful
> for crash dump analysis etc.

It's not quite that, but the gold linker has a --strip-debug-non-line
option which discards all the debugging information except what is
needed to map addresses to lines.

Ian

Re: Making CFLAGS=-g1 bigger but more useful

[Andi Kleen]

On Sat, Apr 25, 2009 at 10:30:51AM -0700, Ian Lance Taylor wrote:
> Andi Kleen <andi@firstfloor.org> writes:
> 
> > On Fri, Apr 24, 2009 at 08:24:56PM -0400, Frank Ch. Eigler wrote:
> >> 
> >> I'm working on a little patch that extends the data produced for the
> >> little-used (?)  -g1 mode.  Normally, this produces very little DWARF
> >> data (basically just function declaration locus, PC range, and basic
> >> backtrace-enabling data).  Compared to normal -g (== -g2) mode, this
> >> is very small.
> >
> > I think what I would like to have is a modus to generate line numbers
> > (so that objdump -S works nicely) but nothing else. That would be useful
> > for crash dump analysis etc.
> 
> It's not quite that, but the gold linker has a --strip-debug-non-line
> option which discards all the debugging information except what is
> needed to map addresses to lines.

The reason I would like to have it is that generating so much data
slows down gcc compilation a lot and there are cases where I don't
need the full data. Striping it in the linker is a start, but
doesn't address the size of the object files. So doing it in the compiler
would be better.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Making CFLAGS=-g1 bigger but more useful

[Ian Lance Taylor]

Andi Kleen <andi@firstfloor.org> writes:

>> It's not quite that, but the gold linker has a --strip-debug-non-line
>> option which discards all the debugging information except what is
>> needed to map addresses to lines.
>
> The reason I would like to have it is that generating so much data
> slows down gcc compilation a lot and there are cases where I don't
> need the full data. Striping it in the linker is a start, but
> doesn't address the size of the object files. So doing it in the compiler
> would be better.

Yes, I agree.

Ian