Re: Namespaces with gcc v3 stabs+?

Re: Namespaces with gcc v3 stabs+?

[Michael Elizabeth Chastain]

mec>  http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01661.html
drow> Wrong URL, that's Daniel in November...

Whoops!  Try this one:

  http://gcc.gnu.org/ml/gcc-patches/2002-05/msg01715.html

Michael C

Re: Namespaces with gcc v3 stabs+?

[Michael Elizabeth Chastain]

Daniel Jacobowitz writes:
> Give me a couple of days?  I want to spend a little time hacking on the
> debug info stuff - I'll try to get to it Monday.

Sure, no hurry on my part.

Michael C

Re: Namespaces with gcc v3 stabs+?

[Michael Elizabeth Chastain]

David Carlton writes:
> 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.

Sounds good to me.  If that's okay with drow, then that's what I'll
request in the bug report.

If gcc doesn't fix the bug at all, then I can point to the bug report
and mark the test case as "xfail".  My view is that, since "xfail" is
caused by a bug in an external program, we'd better have a bug report
to go with it.

> 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?

If the user builds gcc with "--with-stabs", gcc prefers dbx
(the gcc name for stabs).  Besides that, there are about 90 configurations
which default to dbx, most of them without dwarf2 support.  Darwin and
Cygwin are the big ones, with some arm configurations in there.

Michael C

  % cd /berman/migchain/source/gcc-3.2.1/gcc/config
  % grep -r -i dbx_debug *

I found these configurations which prefer dbx:

  darwin.h             dbx, dwarf2
  interix.h            dbx, sdb
  lynx-ng.h            dbx, sdb
  lynx.h               dbx, sdb
  netware.h            dbx
  nextstep.h           dbx
  psos.h               dbx

  alpha/linux-ecoff.h  dbx
  alpha/openbsd.h      dbx
  arc/arc.h            dbx, dwarf-2
  arm/aout.h           dbx
  arm/coff.h           dbx, sdb
  arm/netbsd.h         dbx
  arm/rix-gas.h        dbx
  avr/avr.h            dbx
  convex/convex.h      dbx
  cris/aout.h          dbx
  d30v/d30v.h          dbx
  i386/cygwin.h        dbx, sdb
  i386/i386elf.h       dbx
  i386/gstabs.h        dbx
  i386/i386-interix.h  dbx, sdb
  i386/osf1elfgdb.h    dbx
  i386/osfrose.h       dbx
  i386/sco5.h          dbx, sdb, dwarf, dwarf-2
  i386/sequent.h       dbx
  i386/sol2.h          dbx
  i386/sun.h           dbx
  i386/svr3dbx.h       dbx
  i386/win32.h         dbx, sdb
  i860/bsd.h           dbx
  i860/fx2800.h        dbx
  i960/i960.h          dbx, sdb
  m32r/m32r.h          dbx, dwarf, dwarf-2
  m68k/3b1g.h          dbx
  m68k/altos3068.h     dbx
  m68k/ccur-GAS.h      dbx
  m68k/hp2bsd.h        dbx
  m68k/hp310g.h        dbx
  m68k/hp320g.h        dbx
  m68k/hp3bsd.h        dbx
  m68k/hp3bsd44.h      dbx
  m68k/isi.h           dbx
  m68k/linux.h         dbx
  m68k/linux-aout.h    dbx
  m68k/m68kv4.h        dbx
  m68k/netbsd.h        dbx
  m68k/news.h          dbx
  m68k/openbsd.h       dbx
  m68k/pbb.h           dbx
  m68k/sun2.h          dbx
  m68k/sun3.h          dbx
  m68k/vxm68k.h        dbx
  m88k/aout-dbx.h      dbx
  m88k/luna.h          dbx
  m88k/m88k-aout.h     dbx
  mcore/mcore-pe.h     dbx
  mips/dec-bsd.h       dbx
  mips/elf.h           dbx, dwarf-2
  mips/elf64.h         dbx
  mips/iris5gas.h      dbx, sdb, mips
  mips/isa3264.h       dbx
  mips/netbsd.h        dbx
  mips/openbsd.h       dbx
  mips/osfrose.h       dbx
  mn10200/mn10200.h    dbx
  ns32k/merlin.h       dbx
  ns32k/netbsd.h       dbx
  ns32k/pc532.h        dbx
  ns32k/sequent.h      dbx
  ns32k/tek6000.h      dbx
  pa/pa.h              dbx
  romp/romp.h          dbx
  rs6000/netbsd.h      dbx
  rs6000/vxppc.h       dbx
  sparc/linux64.h      dbx, dwarf2
  sparc/litecoff.h     dbx
  sparc/netbsd.h       dbx
  sparc/openbsd.h      dbx
  sparc/pbd.h          dbx
  sparc/sol2-bi.h      dbx # if TARGET_ARCH32
  sparc/sol2.h         dbx
  sparc/sparc.h        dbx
  sparc/vxsim.h        dbx
  sparc/vxsparc64.h    dbx
  v850/v850.h          dbx
  vax/vax.h            dbx
  vax/vaxv.h           dbx

Re: Namespaces with gcc v3 stabs+?

[David Carlton]

On Fri, 6 Dec 2002 15:05:54 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
> David Carlton writes:

>> 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?

> If the user builds gcc with "--with-stabs", gcc prefers dbx (the gcc
> name for stabs).  Besides that, there are about 90 configurations
> which default to dbx, most of them without dwarf2 support.  Darwin
> and Cygwin are the big ones, with some arm configurations in there.

Thanks for the list.  And Darwin apparently supports DWARF 2.  I'm not
suprised Cygwin is a sticky one, though, now that you mention it.

It seems to me that, for now, it wouldn't be a great idea to convince
GCC to generate a fancy version of stabs, then, until somebody appears
who's particularly motivated to deal with the issues that arise.  So I
agree with your planned course of action.

David Carlton
carlton@math.stanford.edu

Re: Namespaces with gcc v3 stabs+?

[Stan Shebs]

David Carlton wrote:

>On Fri, 6 Dec 2002 15:05:54 -0600, Michael Elizabeth Chastain <mec@shout.net> said:
>
>
>Thanks for the list.  And Darwin apparently supports DWARF 2.  I'm not
>suprised Cygwin is a sticky one, though, now that you mention it.
>
Actually, Darwin doesn't either - I turned it on at one point for
experimentation, but the assembler chokes bigtime.

>
>It seems to me that, for now, it wouldn't be a great idea to convince
>GCC to generate a fancy version of stabs, then, until somebody appears
>who's particularly motivated to deal with the issues that arise.  So I
>agree with your planned course of action.
>
Apple might need to do this.  Dwarf 2 is probably in our future, but
it may be a while, because we can't transition until it's more efficient
to use than stabs.

Stan

Re: Namespaces with gcc v3 stabs+?

[David Carlton]

On Sat, 07 Dec 2002 06:48:21 -0800, Stan Shebs <shebs@apple.com> said:
> David Carlton wrote:

>> It seems to me that, for now, it wouldn't be a great idea to
>> convince GCC to generate a fancy version of stabs, then, until
>> somebody appears who's particularly motivated to deal with the
>> issues that arise.

> Apple might need to do this.

Great; hopefully I'll be able to setup a framework that will make it
relatively easy for y'all, then.

David Carlton
carlton@math.stanford.edu

Re: Namespaces with gcc v3 stabs+?

[Daniel Jacobowitz]

On Fri, Dec 06, 2002 at 03:05:54PM -0600, Michael Elizabeth Chastain wrote:
> David Carlton writes:
> > 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.
> 
> Sounds good to me.  If that's okay with drow, then that's what I'll
> request in the bug report.

Give me a couple of days?  I want to spend a little time hacking on the
debug info stuff - I'll try to get to it Monday.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Namespaces with gcc v3 stabs+?

[Michael Elizabeth Chastain]

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.

Here is a test program:

  namespace AAA
  {
    char mychar;
  }

Here is the output with gcc 2.95.3:

  # gcc 2.95.3, -gstabs+, native i686-pc-linux-gnu
  .stabs "_3AAA.mychar:G(0,2)",32,0,3,0
  .globl _3AAA.mychar
  .bss
	  .type    _3AAA.mychar,@object
	  .size    _3AAA.mychar,1
  _3AAA.mychar:
	  .zero   1

And here is the output with gcc 3.2.1:

  # gcc 3.2.1, -gstabs+, native i686-pc-linux-gnu
  .globl _ZN3AAA6mycharE
	  .bss
	  .type   _ZN3AAA6mycharE,@object
	  .size   _ZN3AAA6mycharE,1
  _ZN3AAA6mycharE:
	  .zero   1
	  .stabs  "mychar:G(0,2)",32,0,3,0

Notice how the stab refers to "mychar", not "_ZN3AAA6mycharE".

The output is similar with gcc 3.0.4, gcc 3.1, gcc 3.1.1, gcc 3.2,
and gcc HEAD%20021203.

Is this ringing any bells?

Kevin B had a similar issue in May 2002:

  http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01661.html

I would like to file a bug report against gcc, and then change
the test script gdb.c++/namespace.exp to XFAIL the test with
stabs+ format and v3 (or later) compilers.

Michael C

Re: Namespaces with gcc v3 stabs+?

[Daniel Jacobowitz]

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.

> Kevin B had a similar issue in May 2002:
> 
>   http://gcc.gnu.org/ml/gcc-patches/2002-11/msg01661.html

Wrong URL, that's Daniel in November...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Namespaces with gcc v3 stabs+?

[David Carlton]

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