From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: dberlin@redhat.com Cc: meissner@cygnus.com, gdb-patches@sources.redhat.com Subject: Re: Forgot to note Date: Wed, 11 Oct 2000 09:53:00 -0000 Message-id: <200010111652.MAA12141@envy.delorie.com> References: <20001010211904.49719@cse.cygnus.com> X-SW-Source: 2000-10/msg00065.html > 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 To: Daniel Berlin Cc: Michael Meissner , 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: <20001010211904.49719@cse.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 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 To: Daniel Berlin 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: 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 To: Stan Shebs Cc: Daniel Berlin , 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: <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 To: Stan Shebs Cc: gdb-patches@sources.redhat.com Subject: Re: Forgot to note Date: Wed, 11 Oct 2000 12:46:00 -0000 Message-id: References: <39E4AEE2.2213F615@apple.com> X-SW-Source: 2000-10/msg00069.html Content-length: 2220 Stan Shebs 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