Re: Forgot to note

[Daniel Berlin <dberlin at redhat dot com>]

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