Re: Forgot to note

Re: Forgot to note

[Kevin Buettner]

[ gdb@sources.redhat.com added to the Cc list. ]

On Oct 10,  8:38pm, Daniel Berlin wrote:

> When the C++ abi moves to the new-abi, I can't fix stabs support
> without either adding a whole bunch of cruft, or making it not support
> the old ABI.
> 
> This is because things like gdb_mangle_name have to be changed to
> handle the new mangling scheme.
> So I have to either detect whether we have old-abi or new-abi
> somewhere, and then add a whole bunch of "if gnu-new-abi" type
> statements, or stop supporting the old abi for stabs/C++.
> 
> Currently, the consensus on gcc seems to be that linux should move to
> dwarf2 before 3.0 releases, which would mean that stopping support for
> new-abi/stabs would also be an option.
> 
> DWARF2 will work fine with either ABI automatically.
> 
> What should we do?
> Not support new-abi/stabs?
> Not support old-abi/stabs?
> Support both? (this is a not insignificant amount of work).

I think we'll need to support both for a period of time.

Here are the reasons:

 1) GDB is should be able to debug executables produced by compilers
    other than GCC.  Some of these may still use stabs with the old
    demangling format.

 2) GDB needs to work with old compilers as well as new ones.  I've
    worked in environments where we used GCC, but we would only switch
    to a new release after a lot of very careful testing.  (And
    sometimes not even then.)  Anyway, switching to a new version of
    GDB was not quite so onerous because it doesn't directly affect
    the quality or correctness of the code comprising an executable
    the way that a compiler or linker does.

    I think it would be unacceptable to force folks to upgrade to
    a particular version of GCC just because they've decided to install
    a new GDB release.

I do think there may come a time when we'll be able to drop support
for the old ABI, but I think that day is a ways off...

It'd be useful if someone could enumerate the compilers which still
produce stabs as the debug info.  For those that don't, but used to,
it'd also be good to know roughly when that support was dropped.

Assuming that we do need to support both, it'd be nice if the code
were arranged in such a way that it'd be easy to rip out the support
for the old ABI when the time comes.

Kevin

Re: Forgot to note

[Daniel Berlin]

Kevin Buettner <kevinb@cygnus.com> writes:

> [ gdb@sources.redhat.com added to the Cc list. ]
> 
> On Oct 10,  8:38pm, Daniel Berlin wrote:
> 
> > When the C++ abi moves to the new-abi, I can't fix stabs support
> > without either adding a whole bunch of cruft, or making it not support
> > the old ABI.
> > 
> > This is because things like gdb_mangle_name have to be changed to
> > handle the new mangling scheme.
> > So I have to either detect whether we have old-abi or new-abi
> > somewhere, and then add a whole bunch of "if gnu-new-abi" type
> > statements, or stop supporting the old abi for stabs/C++.
> > 
> > Currently, the consensus on gcc seems to be that linux should move to
> > dwarf2 before 3.0 releases, which would mean that stopping support for
> > new-abi/stabs would also be an option.
> > 
> > DWARF2 will work fine with either ABI automatically.
> > 
> > What should we do?
> > Not support new-abi/stabs?
> > Not support old-abi/stabs?
> > Support both? (this is a not insignificant amount of work).
> 
> I think we'll need to support both for a period of time.
> 
> Here are the reasons:
> 
>  1) GDB is should be able to debug executables produced by compilers
>     other than GCC.  Some of these may still use stabs with the old
>     demangling format.
I've yet to come across one that does, and I looked *very* hard.
They all use dwarf2.
I didn't look at older versions of compilers, just the current
versions.
Maybe they used to produce stabs?

Also, the new mangling/C++ abi is going to be supported and used by
Sun, HP, Intel, EDG, etc.

> 
>  2) GDB needs to work with old compilers as well as new ones.  I've
>     worked in environments where we used GCC, but we would only switch
>     to a new release after a lot of very careful testing.  (And
>     sometimes not even then.)  Anyway, switching to a new version of
>     GDB was not quite so onerous because it doesn't directly affect
>     the quality or correctness of the code comprising an executable
>     the way that a compiler or linker does.
> 
>     I think it would be unacceptable to force folks to upgrade to
>     a particular version of GCC just because they've decided to install
>     a new GDB release.
>

It's rather easy to keep old-abi/stabs working for C++ (requires just
about nothing) .
It's somewhat more difficult to do new-abi/stabs (requires coding
support for new abi stuff in the current stabs cruft).
It's a real PITA to do both (requires detecting our current ABI, then
supporting both).

So if we didn't support new-abi/stabs, we'd still support
old-abi/stabs just fine.

All we require is that going forward, gcc 3.0 produce dwarf2.
I think this was an eventual goal of the gcc guys anyway, to move all
the older ports to dwarf2 (IIRC, it's now part of the training
program to move a port to dwarf2).

> I do think there may come a time when we'll be able to drop support
> for the old ABI, but I think that day is a ways off...
> 
Hard to say.
That's why i want to bring it up now, to see if we can do it sooner
than a ways off.
> It'd be useful if someone could enumerate the compilers which still
> produce stabs as the debug info.  For those that don't, but used to,
> it'd also be good to know roughly when that support was dropped.

I'd really like this too.
> 
> Assuming that we do need to support both, it'd be nice if the code
> were arranged in such a way that it'd be easy to rip out the support
> for the old ABI when the time comes.

This would require significant rework of how things work right now. 
I'm willing to do it, but it's going to make things unstable for a
while, so it might be better to do it on a branch.
It's also a large amount of code, because it touches almost every
aspect of C++ in GDB, since all this crap is hardcoded in macros and
whatnot rightnow.

> Kevin

Re: Forgot to note

[Eli Zaretskii]

> Date: Tue, 10 Oct 2000 18:16:45 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> It'd be useful if someone could enumerate the compilers which still
> produce stabs as the debug info.

The DJGPP port of GCC still uses stabs.  (It also supports COFF, but
that's almost useless for C++ debugging.)  I'm not aware of any work
being done to port dwarf2 to DJGPP.