Re: Forgot to note

[Kevin Buettner <kevinb@cygnus.com>]

[ 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
From meissner@cygnus.com Tue Oct 10 18:19:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 18:19:00 -0000
Message-id: <20001010211904.49719@cse.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00054.html
Content-length: 1462

On Tue, Oct 10, 2000 at 08:38:50PM -0400, 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 the only realistic solution is to support both.  Note, Linux is not the
only system out there that uses stabs (many of the embedded systems do to).
What are you going to do, compile some code with the new abi if no debugging
option were used and use the old abi if -g was used (on a system that supports
stabs as the native format).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482
From dberlin@redhat.com Tue Oct 10 19:29:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Michael Meissner <meissner@cygnus.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Tue, 10 Oct 2000 19:29:00 -0000
Message-id: <m3bswsds9s.fsf@dan2.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com>
X-SW-Source: 2000-10/msg00056.html
Content-length: 1967

Michael Meissner <meissner@cygnus.com> writes:

> On Tue, Oct 10, 2000 at 08:38:50PM -0400, 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 the only realistic solution is to support both.  Note, Linux is not the
> only system out there that uses stabs (many of the embedded systems do to).
> What are you going to do, compile some code with the new abi if no debugging
> option were used and use the old abi if -g was used (on a system that supports
> stabs as the native format).
>

It's arguably a *lot* simpler to change those platforms to dwarf2,
then to support new-abi/stabs *and* old-abi/stabs at the same time.

One is a case of changing a define in a gcc config file (correct me if
i'm incorrect here, I'm under the impression it should only really
require changing the DEFAULT_DEBUGGING_FORMAT, and possibly redefining
a few macros.), the other, writing a whole bunch of new code.


Remember, if we leave stabs support as is, it'll handle the old-abi
case fine. It's the new-abi that will kill it. So those platforms only
need to be using dwarf2 going forward, not going backwards.


--Dan