From: Daniel Berlin <dan@cgsoftware.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: dan@cgsoftware.com, jtc@redback.com, gdb@sourceware.cygnus.com,
binutils@sourceware.cygnus.com
Subject: Re: stabs vs. dwarf-2 for C programs
Date: Fri, 13 Apr 2001 08:13:00 -0000 [thread overview]
Message-ID: <m2ae5kn887.fsf@dynamic-addr-83-177.resnet.rochester.edu> (raw)
In-Reply-To: <200104130637.CAA07371@delorie.com>
Eli Zaretskii <eliz@delorie.com> writes:
> > From: Daniel Berlin <dan@cgsoftware.com>
> > Date: 12 Apr 2001 22:54:44 -0400
> >
> > jtc@redback.com (J.T. Conklin) writes:
> >
> > > In general, are there any advantages for using dwarf-2 over
> > > stabs debugging symbols for C (not C++) programs?
> >
> > Unless you want optimized code debugging, only space savings
> > (theoretical, of course, right now. For C, anyway).
>
> I _always_ debug optimized code (I think doing otherwise is not wise,
> to put it gently). What are the advantages of dwarf2 for debugging
> optimized C code?
Any variable, not optimized out (excluding interprocedural
optimizations that cause very weird things, like a variable to be
split into two different object file sections, also known as
discontiguous scopes, which won't be
supported until DWARF 2.1), can be viewed just fine.
When I get done teaching GDB a little more, you'll not be able to
notice the difference between inline functions, and non-inline
ones. We can present them to the user as if they weren't inlined (IE
having their own frame, being able to breakpoint in them, etc), without any trouble.
Lots of other stuff too.
I know of a few compilers/debuggers that use DWARF2 to it's fullest
abilities to describe optimized code, and you can't tell the
difference between debugging a program compiled with optimization, and
without.
--
I love to go shopping. I love to freak out salespeople. They
ask me if they can help me, and I say, "Have you got anything
I'd like?" Then they ask me what size I need, and I say, "Extra
medium."
next prev parent reply other threads:[~2001-04-13 8:13 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-12 19:13 J.T. Conklin
2001-04-12 19:17 ` Christopher Faylor
2001-04-12 19:31 ` J.T. Conklin
2001-04-12 19:59 ` Daniel Berlin
2001-04-13 7:13 ` John Haller
2001-04-13 8:09 ` Daniel Berlin
2001-04-13 16:18 ` Ian Lance Taylor
2001-04-13 18:39 ` Daniel Berlin
2001-04-13 20:22 ` Ian Lance Taylor
2001-04-13 22:01 ` Daniel Berlin
2001-04-13 22:19 ` Ian Lance Taylor
2001-04-13 22:37 ` DJ Delorie
2001-04-13 23:31 ` Daniel Berlin
2001-04-13 23:47 ` Daniel Berlin
2001-04-13 23:51 ` Ian Lance Taylor
2001-04-13 22:56 ` Daniel Berlin
2001-04-13 23:40 ` Ian Lance Taylor
2001-04-13 23:55 ` Todd Whitesel
2001-04-12 19:55 ` Daniel Berlin
2001-04-12 23:37 ` Eli Zaretskii
2001-04-13 8:13 ` Daniel Berlin [this message]
2001-04-12 22:00 ` Geoff Keating
2001-04-12 22:37 ` Daniel Berlin
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=m2ae5kn887.fsf@dynamic-addr-83-177.resnet.rochester.edu \
--to=dan@cgsoftware.com \
--cc=binutils@sourceware.cygnus.com \
--cc=eliz@is.elta.co.il \
--cc=gdb@sourceware.cygnus.com \
--cc=jtc@redback.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