Re: Forgot to note

[Daniel Berlin <dberlin@redhat.com>]

Michael Meissner <meissner@cygnus.com> writes:

> 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.
Forgot about those.
I sincerely hope someone will help fund part of this work, because
it's going to be a lot for me to be the only one to handle.
It's also hard to motivate myself to do it, unless I become scheduled
to do it, mainly because I can envinsion just how hairy it's going to
become.

> 
> > 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.
Probably right, i'm just really trying to avoid the inveitable.
--Dan