Re: Forgot to note

[Michael Meissner <meissner at cygnus dot com>]

On Tue, Oct 10, 2000 at 10:29:51PM -0400, Daniel Berlin wrote:
> 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.

What I'm worried about is all of the non-ELF ports, where you can't create
arbitrary sections and/or don't have a way to emit an address relocation to an
unaligned address (and hence can't do dwarf-2).  For example, in the past, MIPS
ECOFF used stabs and could not create arbitrary sections.  I know in the past,
there were cases where we used the host assembler and used stabs.  Until
somebody goes through and checks every single port on the FSF repository (and
somebody within Red Hat should check the various ports that are not yet donated
to the FSF), I believe you should plan to support new-abi via stabs.

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

I think this is too narrow of a viewpoint.

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