Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: David Carlton <carlton@math.stanford.edu>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: Michael Elizabeth Chastain <mec@shout.net>, gdb@sources.redhat.com
Subject: Re: Namespaces with gcc v3 stabs+?
Date: Fri, 06 Dec 2002 11:25:00 -0000	[thread overview]
Message-ID: <ro1vg27ueyw.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <20021206011508.GB28778@nevyn.them.org>

On Thu, 5 Dec 2002 20:15:08 -0500, Daniel Jacobowitz <drow@mvista.com> said:
> On Thu, Dec 05, 2002 at 06:31:55PM -0600, Michael Elizabeth Chastain wrote:

>> Question for Daniel J or David C or Kevin B or anybody who knows
>> about v3 and stabs support ...

>> I'm looking at disimprovements from gcc v2 to gcc v3.  One of the
>> issues is that gcc 2.95.3 / stabs+ emits stab information
>> for symbols in namespaces, but gcc 3.2.1 / stabs+ emits the stab
>> information with the wrong name.

> Erk.  Obviously GCC is wrong.  Just the name is not useful.

> What do we want it to do, David?  If we're going to get stabs
> changed in GCC anyway, we could get explicit namespace markers, and
> leave the demangled name in the stabs.  That's parallel to the
> DWARF-2 approach.

I'm not sure.  I'm not a stabs expert, but what I've heard about it
makes me not too eager to spend too much time supporting it if it's
the case that encouraging users to migrate to DWARF 2 is a viable
option.  Which means that, for now, I'm mostly concerned about
supporting namespaces in two ways:

1) DWARF 2 with full namespace debugging information: here we
   obviously want to get everything correct.

2) Debug formats without full namespace debugging information
   (including but not limited to DWARF 2 as currently generated by
   GCC): here we want to infer the presence of namespaces as much as
   is practical.

Supporting stabs at the second level of support seems to me easy
enough and reasonably important.  But converting stabs to the better
level of support would take energy both from us and from GCC, and I'm
not sure that energy is the best possible investment.

So for now I'd lean towards getting GCC to emit stabs+ info as it did
in 2.95.3: that should be cheap on everybody's part, and profitable
enough.

What systems are there that GCC supports for which stabs+ can be used
but DWARF 2 can't?  How important are they?  Who's supporting them?
Are there other more modern debug formats that really should be used
on those systems in place of stabs?

(Admittedly, right now I'm a little more mad at stabs than normal: I
just noticed the #if 1 bit in c-exp.y's yylex() last week, and now I
have the charming task of getting rid of that hack while preserving as
much of the current behavior for stabs users as possible...)

David Carlton
carlton@math.stanford.edu


  reply	other threads:[~2002-12-06 19:25 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-05 16:31 Michael Elizabeth Chastain
2002-12-05 17:14 ` Daniel Jacobowitz
2002-12-06 11:25   ` David Carlton [this message]
2002-12-05 18:06 Michael Elizabeth Chastain
2002-12-06 13:06 Michael Elizabeth Chastain
2002-12-06 17:27 ` David Carlton
2002-12-07  6:49   ` Stan Shebs
2002-12-09 10:59     ` David Carlton
2002-12-06 17:58 ` Daniel Jacobowitz
2002-12-06 19:48 Michael Elizabeth Chastain

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=ro1vg27ueyw.fsf@jackfruit.Stanford.EDU \
    --to=carlton@math.stanford.edu \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=mec@shout.net \
    /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