From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: gdb-patches@sources.redhat.com Cc: gdb@sources.redhat.com Subject: Re: Forgot to note Date: Tue, 10 Oct 2000 18:19:00 -0000 Message-id: <1001011011645.ZM2970@ocotillo.lan> References: X-SW-Source: 2000-10/msg00055.html [ gdb@sources.redhat.com added to the Cc list. ] On Oct 10, 8:38pm, 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 we'll need to support both for a period of time. Here are the reasons: 1) GDB is should be able to debug executables produced by compilers other than GCC. Some of these may still use stabs with the old demangling format. 2) GDB needs to work with old compilers as well as new ones. I've worked in environments where we used GCC, but we would only switch to a new release after a lot of very careful testing. (And sometimes not even then.) Anyway, switching to a new version of GDB was not quite so onerous because it doesn't directly affect the quality or correctness of the code comprising an executable the way that a compiler or linker does. I think it would be unacceptable to force folks to upgrade to a particular version of GCC just because they've decided to install a new GDB release. I do think there may come a time when we'll be able to drop support for the old ABI, but I think that day is a ways off... It'd be useful if someone could enumerate the compilers which still produce stabs as the debug info. For those that don't, but used to, it'd also be good to know roughly when that support was dropped. Assuming that we do need to support both, it'd be nice if the code were arranged in such a way that it'd be easy to rip out the support for the old ABI when the time comes. Kevin >From meissner@cygnus.com Tue Oct 10 18:19:00 2000 From: Michael Meissner To: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: Forgot to note Date: Tue, 10 Oct 2000 18:19:00 -0000 Message-id: <20001010211904.49719@cse.cygnus.com> References: X-SW-Source: 2000-10/msg00054.html Content-length: 1462 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). -- 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 dberlin@redhat.com Tue Oct 10 19:29:00 2000 From: Daniel Berlin To: Michael Meissner Cc: gdb-patches@sources.redhat.com Subject: Re: Forgot to note Date: Tue, 10 Oct 2000 19:29:00 -0000 Message-id: References: <20001010211904.49719@cse.cygnus.com> X-SW-Source: 2000-10/msg00056.html Content-length: 1967 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. 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