public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: David Taylor <dtaylor@emc.com>
Cc: Daniel Berlin <dberlin@dberlin.org>,
	gcc@gcc.gnu.org, gdb@sources.redhat.com
Subject: Re: stabs and macro information
Date: Thu, 17 Apr 2003 16:46:00 -0000	[thread overview]
Message-ID: <20030417164643.GA8469@nevyn.them.org> (raw)
In-Reply-To: <200304171639.h3HGdNA23643@mailhub.lss.emc.com>

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

  reply	other threads:[~2003-04-17 16:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-16 15:58 David Taylor
2003-04-16 16:47 ` Daniel Berlin
2003-04-16 17:16   ` David Taylor
2003-04-16 17:25     ` Daniel Jacobowitz
2003-04-16 17:38     ` Andrew Cagney
2003-04-16 17:27 ` Daniel Jacobowitz
2003-04-16 17:59   ` David Taylor
2003-04-16 20:29   ` Daniel Berlin
2003-04-17 16:39     ` David Taylor
2003-04-17 16:46       ` Daniel Jacobowitz [this message]
2003-04-24  3:20 ` Jim Blandy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030417164643.GA8469@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=dberlin@dberlin.org \
    --cc=dtaylor@emc.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).