Re: stabs and macro information

[David Taylor <dtaylor@emc.com>]

> 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