stabs and macro information

stabs and macro information

[David Taylor]

Currently, when invoked with -gdwarf-2 -g3, gcc will record macro
information in a .debug_macinfo elf section.  And when presented with
an executable containing macro information in a .debug_macinfo
section, gdb will make use of it.

Many companies, including EMC, still use stabs.  So...  it would be
nice if the same was true of stabs.

To that end, I have started to implement this.

The GCC side of things took less than a day to implement; I'm hoping
to get started on the GDB side soon.

One question I have is what stabs types to use -- tentatively I'm using:

    /* GNU extension.  Macro define.  */
    __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE")

    /* GNU extension.  Macro undefine.  */
    __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF")

as it appears (based on gcc/stab.def, include/aout/stab.def, and
gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available.

Is anyone aware of any other uses of stab types 0x36 and 0x3a --
i.e. is anyone aware of uses that might conflict?

Thanks.

David

p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged?
--
David Taylor
dtaylor@emc.com

Re: stabs and macro information

[Daniel Berlin]

On Wednesday, April 16, 2003, at 11:58  AM, David Taylor wrote:

> Currently, when invoked with -gdwarf-2 -g3, gcc will record macro
> information in a .debug_macinfo elf section.  And when presented with
> an executable containing macro information in a .debug_macinfo
> section, gdb will make use of it.
>
> Many companies, including EMC, still use stabs.  So...  it would be
> nice if the same was true of stabs.

>
> To that end, I have started to implement this.
>
> The GCC side of things took less than a day to implement; I'm hoping
> to get started on the GDB side soon.
>
I didn't see it on the GCC list. Was it submitted?
I ask because ...

> One question I have is what stabs types to use -- tentatively I'm 
> using:
>
>     /* GNU extension.  Macro define.  */
>     __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE")

>     /* GNU extension.  Macro undefine.  */
>     __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF")
>
Unless these are really generated by GCC, they aren't GNU extensions, 
they are EMC extensions.

> as it appears (based on gcc/stab.def, include/aout/stab.def, and
> gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available.
>
> Is anyone aware of any other uses of stab types 0x36 and 0x3a --
> i.e. is anyone aware of uses that might conflict?
>
You might want to look at what Sun's tools do.
Do they generate STABS anymore, and if so, see if they have extensions 
that conflict here.
> Thanks.
>
> David
>
> p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged?

Possibly.
I would imagine that nobody seriously cares about *extending* STABS 
anymore, so nobody has had any motivation to do anything about it.

--Dan

Re: stabs and macro information

[David Taylor]

> Date: Wed, 16 Apr 2003 12:47:17 -0400
> From: Daniel Berlin <dberlin@dberlin.org>
> 
> On Wednesday, April 16, 2003, at 11:58  AM, David Taylor wrote:
> 
> > The GCC side of things took less than a day to implement; I'm hoping
> > to get started on the GDB side soon.
> >
> I didn't see it on the GCC list. Was it submitted?
> I ask because ...

Not yet.  The copyright assignment paperwork for EMC's changes to GCC
hasn't been approved/signed yet by management.  I expect it will be
approved/signed, but it hasn't been yet.

[I feel that it is inappropriate to post changes if they are not
assigned (unless they are small enough to not need an assignment).

However, I do feel it is appropriate to discuss how to do it / what to
name things / etc. as the changes are likely to be assigned.]

Also, since the GDB part isn't done yet, the GCC part isn't
particularly useful as yet.

[NOTE: GDB copyright assignment papers *have* been signed.]

> > One question I have is what stabs types to use -- tentatively I'm 
> > using:
> >
> >     /* GNU extension.  Macro define.  */
> >     __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE")
> 
> >     /* GNU extension.  Macro undefine.  */
> >     __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF")
> >
> Unless these are really generated by GCC, they aren't GNU extensions, 
> they are EMC extensions.

You are correct that they are currently EMC extensions.  After the
change gets submitted, if it is accepted, then it will be a GNU
extension.

> > as it appears (based on gcc/stab.def, include/aout/stab.def, and
> > gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available.
> >
> > Is anyone aware of any other uses of stab types 0x36 and 0x3a --
> > i.e. is anyone aware of uses that might conflict?
> >
> You might want to look at what Sun's tools do.
> Do they generate STABS anymore, and if so, see if they have extensions 
> that conflict here.

I don't currently have access to Sun's tools.  Also, Sun used to be
(might still be for all I know) rather secretive about their stabs
extensions.  Does Sun document their stabs stuff in a publicly
accessible document?

I don't know if Sun's tools still generate stabs or not.

> > Thanks.
> >
> > David
> >
> > p.s. shouldn't include/aout/stab.def and gcc/stab.def be merged?
> 
> Possibly.
> I would imagine that nobody seriously cares about *extending* STABS 
> anymore, so nobody has had any motivation to do anything about it.
> 
> --Dan

Later,

David

Re: stabs and macro information

[Daniel Jacobowitz]

On Wed, Apr 16, 2003 at 01:16:20PM -0400, David Taylor wrote:
> I don't currently have access to Sun's tools.  Also, Sun used to be
> (might still be for all I know) rather secretive about their stabs
> extensions.  Does Sun document their stabs stuff in a publicly
> accessible document?

They did as recently as 1999, and there is no mention of macros in the
manual.  I think it's on their website somewhere.

> I don't know if Sun's tools still generate stabs or not.

I believe they do.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: stabs and macro information

[Andrew Cagney]

> Not yet.  The copyright assignment paperwork for EMC's changes to GCC
> hasn't been approved/signed yet by management.  I expect it will be
> approved/signed, but it hasn't been yet.
> 
> [I feel that it is inappropriate to post changes if they are not
> assigned (unless they are small enough to not need an assignment).

This is really appreciated.

> However, I do feel it is appropriate to discuss how to do it / what to
> name things / etc. as the changes are likely to be assigned.]

Yes.  Technical aspects should be fleshed out up front.  That way all 
parties concerned know what has been agreed to.  Just leaves the small 
issue of implementation :-)

Andrew

Re: stabs and macro information

[Daniel Jacobowitz]

On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote:
> Currently, when invoked with -gdwarf-2 -g3, gcc will record macro
> information in a .debug_macinfo elf section.  And when presented with
> an executable containing macro information in a .debug_macinfo
> section, gdb will make use of it.
> 
> Many companies, including EMC, still use stabs.  So...  it would be
> nice if the same was true of stabs.

A more interesting question, to me, is why EMC still needs to use
stabs.  They are an inferior debug format, extremely hard to parse or
extend.  GCC's and GDB's current implementations of DWARF-2 (and 3) are
somewhat lacking, but it's all fixable.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: stabs and macro information

[David Taylor]

> Date: Wed, 16 Apr 2003 13:27:04 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote:
> > Currently, when invoked with -gdwarf-2 -g3, gcc will record macro
> > information in a .debug_macinfo elf section.  And when presented with
> > an executable containing macro information in a .debug_macinfo
> > section, gdb will make use of it.
> > 
> > Many companies, including EMC, still use stabs.  So...  it would be
> > nice if the same was true of stabs.
> 
> A more interesting question, to me, is why EMC still needs to use
> stabs.  They are an inferior debug format, extremely hard to parse or
> extend.

EMC does some processing of stabs via in house tools.  I'm told that
at one point before I started here that they switched to dwarf for a
bit.  And that the dwarf that was generated by GCC (and hence had to
be handled by the local tools) changed a few times...  They got tired
of having to modify the in house tools, so they switched back to
stabs.

>          GCC's and GDB's current implementations of DWARF-2 (and 3) are
> somewhat lacking, but it's all fixable.

I imagine we will eventually switch.  But, as long as the gcc and gdb
dwarf implementations are perceived as 'somewhat lacking', it's harder
to make the case to management.

Re: stabs and macro information

[Daniel Berlin]

On Wednesday, April 16, 2003, at 01:27  PM, Daniel Jacobowitz wrote:

> On Wed, Apr 16, 2003 at 11:58:19AM -0400, David Taylor wrote:
>> Currently, when invoked with -gdwarf-2 -g3, gcc will record macro
>> information in a .debug_macinfo elf section.  And when presented with
>> an executable containing macro information in a .debug_macinfo
>> section, gdb will make use of it.
>>
>> Many companies, including EMC, still use stabs.  So...  it would be
>> nice if the same was true of stabs.
>
> A more interesting question, to me, is why EMC still needs to use
> stabs.
I didn't want to get into this argument, as there are companies that 
have valid reasons not to use DWARF2 given the current implementations, 
particularly those compaonies that end up with 1 gigabyte with stabs 
info, and 5 gigabytes with dwarf2 info, or something like that.

However, I was going to ask whether the cost of *adding* more features 
to the STABS implementations in gdb and gcc is worth the future 
maintenance cost at this point in the life of STABS.
> They are an inferior debug format, extremely hard to parse or
> extend.  GCC's and GDB's current implementations of DWARF-2 (and 3) are
> somewhat lacking, but it's all fixable.

And, more importantly, in the process of being fixed.
:)

>
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

Re: stabs and macro information

[David Taylor]

> Date: Wed, 16 Apr 2003 16:29:54 -0400
> From: Daniel Berlin <dberlin@dberlin.org>
> 
> On Wednesday, April 16, 2003, at 01:27  PM, Daniel Jacobowitz wrote:
> 
> > A more interesting question, to me, is why EMC still needs to use
> > stabs.

> I didn't want to get into this argument, as there are companies that 
> have valid reasons not to use DWARF2 given the current implementations, 
> particularly those compaonies that end up with 1 gigabyte with stabs 
> info, and 5 gigabytes with dwarf2 info, or something like that.

Agreed.  I was talking earlier yesterday with the author of some of
the internal tools that manipulate STABS.  At least part of the reason
for preferring STABS is the sheer size of the DWARF information.

I believe that eliminating duplication of information so that DWARF is
comparable in size to STABS will go a long way towards reducing
people's resistance to DWARF.

Stability in how information is encoded will also help.

Another complaint I heard was how DWARF is a mixture of binary and
text whereas STABS is just text -- therefore making STABS easier to
parse by Perl.

[I believe that the person making this complaint feels much more
comfortable with Perl than with C.]

> However, I was going to ask whether the cost of *adding* more features 
> to the STABS implementations in gdb and gcc is worth the future 
> maintenance cost at this point in the life of STABS.

The GCC cost seems low.  Factoring out the interrupts and related
items that occurred during the implementation, testing, and debugging,
I would guess that it was less than one day to do all three.

Let's see, I modified 3 files, c-lex.c, dbxout.c, and stab.def.

	* c-lex.c (init_c_lex):  Set cb->define and cb->undef for
	DBX_DEBUG, too.
	* dbxout.c (dbxout_define, dbxout_undef):  New functions;
	handle macro define and undef for STABS.
	(dbx_debug_hooks):  Initialize define and undef fields to
	dbxout_define and dbxout_undef, respectively.
	* stab.def (N_MAC_DEFINE, N_MAC_UNDEF):  New entries.

In c-lex.c, I modified 1 (one!) if statement to add DBX_DEBUG as a
case where you want to initialize cb->define and cb->undef.  Not a
big deal.

In stab.def, I've already posted the lines that got added.  Also
trivial.

In dbxout.c, I added two simple functions and arranged for them to be
called.  Taking dbxout_define, here's how simple the body of it is:

  if (debug_info_level >= DINFO_LEVEL_VERBOSE)
    {
      fprintf (asmfile, "%s", ASM_STABS_OP);
      output_quoted_string (asmfile, buffer);
      fprintf (asmfile, ",%d,0,%d,0\n", N_MAC_DEFINE, lineno);
    }

That is it.  Nothing more.  And dbxout_undef is *VERY* similar.

Given how easy it is and given that I don't think that STABS is going
to go away anytime soon, I think it's worth it.  Perhaps I'm wrong.

[But, it's worth it to us.  And even if the change, when it's
eventually posted, is not accepted, we will likely maintain this
difference as long as we continue to use STABS.]

> > They are an inferior debug format, extremely hard to parse or
> > extend.  GCC's and GDB's current implementations of DWARF-2 (and 3) are
> > somewhat lacking, but it's all fixable.
> 
> And, more importantly, in the process of being fixed.
> :)

Ummm, I would have to disagree about the first part.

STABS is pretty easy to extend.  I haven't done the GDB part yet; but,
while I imagine it will take longer to do than the GCC part, I don't
expect it to take a long time and I expect that the bulk of the time
will be becoming enough familiar with the macro table stuff in GDB to
make the right calls.  How to modify GDB's STABS parser looks pretty
straightforward.

I think that a large part of STABS' problem, historically, is that

    . it was easy to extend,

    . there was no one charged with resolving conflicts between
      conflicting extensions, and

    . it was undocumented.

[Because it was undocumented, in a conflict between a STABS producer
and a STABS consumer, you couldn't say definitively who was right and
who was wrong.  We live with the result.]

That the problems with GCC's and GDB's implementations of DWARF are
being addressed is important.

I feel that saying that DWARF is a superior *format* is irrelevant if
the implementation is not superior.  As the implementation improves
and the size of the DWARF info decreases, people will be more likely
to embrace DWARF.  The size of the information is an issue for us.

> >
> > -- 
> > Daniel Jacobowitz
> > MontaVista Software                         Debian GNU/Linux Developer

Later,

David
--
David Taylor
dtaylor@emc.com

Re: stabs and macro information

[Daniel Jacobowitz]

On Thu, Apr 17, 2003 at 12:39:21PM -0400, David Taylor wrote:
> > > They are an inferior debug format, extremely hard to parse or
> > > extend.  GCC's and GDB's current implementations of DWARF-2 (and 3) are
> > > somewhat lacking, but it's all fixable.
> > 
> > And, more importantly, in the process of being fixed.
> > :)
> 
> Ummm, I would have to disagree about the first part.
> 
> STABS is pretty easy to extend.  I haven't done the GDB part yet; but,
> while I imagine it will take longer to do than the GCC part, I don't
> expect it to take a long time and I expect that the bulk of the time
> will be becoming enough familiar with the macro table stuff in GDB to
> make the right calls.  How to modify GDB's STABS parser looks pretty
> straightforward.

No.  Your extensions are an example of a kind which would be easy to
add; but for some C++ concepts which DWARF-2 can express, it would be a
heck of a lot harder.  Inline functions, templates, namespaces (Sun has
recent extensions for at least this one), virtual inheritance (we can
do this now but you'll see what I mean about gross extensions if you
look at how!), et cetera.

A better example is .debug_loc; location lists in stabs would be
extremely difficult to integrate into the stabs text format.

> That the problems with GCC's and GDB's implementations of DWARF are
> being addressed is important.
> 
> I feel that saying that DWARF is a superior *format* is irrelevant if
> the implementation is not superior.  As the implementation improves
> and the size of the DWARF info decreases, people will be more likely
> to embrace DWARF.  The size of the information is an issue for us.

These are not the only implementations in the world.  Sadly, right now
they aren't close to the best, either.  There are some interesting
existance proofs, in e.g. the Intel tools.

As for text vs binary - there are at least two good DWARF-2 dumpers,
readelf and dwarfdump; I find their output a whole lot easier to make
sense of than stabs.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: stabs and macro information

[Jim Blandy]

David Taylor <dtaylor@emc.com> writes:
> One question I have is what stabs types to use -- tentatively I'm using:
> 
>     /* GNU extension.  Macro define.  */
>     __define_stab(N_MAC_DEFINE, 0x36, "MAC_DEFINE")
> 
>     /* GNU extension.  Macro undefine.  */
>     __define_stab(N_MAC_UNDEF, 0x3a, "MAC_UNDEF")
> 
> as it appears (based on gcc/stab.def, include/aout/stab.def, and
> gdb/doc/stabs.texinfo) that 0x36 and 0x3a are available.
> 
> Is anyone aware of any other uses of stab types 0x36 and 0x3a --
> i.e. is anyone aware of uses that might conflict?

At least according to Version 4.0 of Sun's _Stabs Interface Manual_,
dated February 1999, those numbers are not in use.

The _Stabs Interface Manual_ is not available on the web.  I wrote to
Sun asking why it wasn't; they told me that it was included with the
Sun toolchain, and was deliberately not available on the web.