From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Berlin To: Michael Meissner Cc: gdb-patches@sources.redhat.com Subject: Re: Forgot to note Date: Wed, 11 Oct 2000 12:55:00 -0000 Message-id: References: <20001010211904.49719@cse.cygnus.com> <20001011130611.11730@cse.cygnus.com> X-SW-Source: 2000-10/msg00071.html Michael Meissner writes: > 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. 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