Re: Forgot to note

[DJ Delorie <dj@delorie.com>]

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

OK, I'll let you change DJGPP's built-in crash analyzer program, which
only understands stabs, and the mini-debuggers (edebug32, fsdb) and
IDE (rhide), which also only understand stabs.  No, they don't use
BFD.  No, gdb isn't an option to replace those.  Oh, and the different
parts of DJGPP are released asynchronously, so you'll have to fix
those long before you remove support in gcc, so we have a chance to
run through a release cycle (we release every few years) and get these
updates to users before the new gcc comes out.

Not that I object to moving djgpp to dwarf2 (people hate stabs/C++
debugging) but there's a lot of other things that have to change in
conjunction with changing the compiler.
From meissner@cygnus.com Wed Oct 11 10:06:00 2000
From: Michael Meissner <meissner@cygnus.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: Michael Meissner <meissner@cygnus.com>, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 10:06:00 -0000
Message-id: <20001011130611.11730@cse.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <20001010211904.49719@cse.cygnus.com> <m3bswsds9s.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00066.html
Content-length: 2976

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
From shebs@apple.com Wed Oct 11 11:18:00 2000
From: Stan Shebs <shebs@apple.com>
To: Daniel Berlin <dberlin@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 11:18:00 -0000
Message-id: <39E4AEE2.2213F615@apple.com>
References: <m33di46wkl.fsf@dan2.cygnus.com>
X-SW-Source: 2000-10/msg00067.html
Content-length: 1325

Daniel Berlin wrote:
> 
> 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.

I Don't Think So...

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

Guess what, you're going to have to work harder. :-)

The only valid rationale for skipping new-abi/stabs support was if
GCC itself was no longer going to support stabs with the new ABI.
I haven't heard that that was going to happen, and it seems
implausible anyway because of the magnitude of the disruption.

As a transition strategy it would be acceptable to work up
placeholders in stabs support so that we can add stuff incrementally.
For instance, Apple may or may not be moving off stabs in the
GCC 3.0 timeframe, so we may be motivated to do some of the actual
new-abi/stabs work.

Even under an optimistic dwarf2 adoption scenario (dwarf2 still
hasn't been standardized for one thing, although it's getting
close), the stabs format is going to be with us for at least another
five years, so you should plan your hacking so that you can live with
the stabs reader for that long.

Stan
From eager@eagercon.com Wed Oct 11 11:25:00 2000
From: Michael Eager <eager@eagercon.com>
To: Stan Shebs <shebs@apple.com>
Cc: Daniel Berlin <dberlin@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 11:25:00 -0000
Message-id: <39E4B09A.D096436F@eagercon.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <39E4AEE2.2213F615@apple.com>
X-SW-Source: 2000-10/msg00068.html
Content-length: 804

Stan Shebs wrote:
> 
> Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> hasn't been standardized for one thing, although it's getting
> close), the stabs format is going to be with us for at least another
> five years, so you should plan your hacking so that you can live with
> the stabs reader for that long.

FYI, the current plan is to consider all of the proposals for 
changes to Dwarf 2 by the end of this year and release a version
of the revised standard for public review early in 2001.

My experience is the same as Stan's.  Old formats don't disappear,
and they certainly don't disappear because someone says that they
should.  Plan for a long End-Of-Life status.

-- 
Michael Eager	 Eager Consulting     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
From dberlin@redhat.com Wed Oct 11 12:46:00 2000
From: Daniel Berlin <dberlin@redhat.com>
To: Stan Shebs <shebs@apple.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: Forgot to note
Date: Wed, 11 Oct 2000 12:46:00 -0000
Message-id: <m3bswr88kg.fsf@dan2.cygnus.com>
References: <m33di46wkl.fsf@dan2.cygnus.com> <39E4AEE2.2213F615@apple.com>
X-SW-Source: 2000-10/msg00069.html
Content-length: 2220

Stan Shebs <shebs@apple.com> writes:

> Daniel Berlin wrote:
> > 
> > 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.
> 
> I Don't Think So...
> 
> > 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).
> 
> Guess what, you're going to have to work harder. :-)


Not necessarily me, it depends on my schedule.
It may end up  that i won't have time to add support for new-abi/stabs
anytime soon.
> The only valid rationale for skipping new-abi/stabs support was if
> GCC itself was no longer going to support stabs with the new ABI.
> I haven't heard that that was going to happen, and it seems
> implausible anyway because of the magnitude of the disruption.
> 
Right.

> As a transition strategy it would be acceptable to work up
> placeholders in stabs support so that we can add stuff incrementally.
> For instance, Apple may or may not be moving off stabs in the
> GCC 3.0 timeframe, so we may be motivated to do some of the actual
> new-abi/stabs work.

Hey, that'd be nice.

> 
> Even under an optimistic dwarf2 adoption scenario (dwarf2 still
> hasn't been standardized for one thing, although it's getting
> close),

That's not really fair to say.
1. Dwarf2 *has* been adopted. Compilers either use it (most), or plan
on using it.
Nobody plans on using something else in the future, AFAIK.
2. It wasn't "officially" standardized because the sponsor went broke.
There is a draft standard, and this is what people use.
Mike eager also is driving the 2.1 standard.

< the stabs format is going to be with us for at least another
> five years, so you should plan your hacking so that you can live with
> the stabs reader for that long.
> 
It's not the stabs reader i'm worried about.
It's all the crufty stupidity specifically related to C++/stabs that
is going to break.

Just wanted to see if I could remove it yet, but apparently not.
I certainly don't want to add to it, but it appears i'm going to have
to.


> Stan