| Message ID | c11f2200-0106-7b87-cc39-3d33ed22f9d0@acm.org |
|---|---|
| State | New |
| Headers | show |
On Jul 21, 2017, at 6:07 AM, Nathan Sidwell <nathan@acm.org> wrote: > > [darwin, cygwin, rx maintainers, you might have an opinion] darwin going forward is a DWARF platform, so, shouldn't be a heartache for real folks. For ancient machines, ancient compilers might be a requirement. Generally, I like keeping things; but cleanups and removals are a part of life, and eventually the old should be removed. I'd not stand in the way of such removal. If we were within 5 years of such a transition point, I'd argue to keep it for at least 5 years. But, the switch for darwin was Oct 26th, 2007. 10 years I think is a nice cutover point for first tier things. Beyond 10, and I'd say, you are dragging your feet. If _all_ the code for DBX were in my port file, I'd be tempted to keep it indefinitely. It's not, so, that's not possible/reasonable. Iain, do you still have the G5s? :-) Do they run 8 or 9? What do you think? Seem reasonable? The 64_BIT x86 darwin question likely can be be flipped to default to dwarf; so, even that isn't an issue.
> On 21 Jul 2017, at 20:10, Mike Stump <mikestump@comcast.net> wrote: > > On Jul 21, 2017, at 6:07 AM, Nathan Sidwell <nathan@acm.org> wrote: >> >> [Darwin, cygwin, rx maintainers, you might have an opinion] > > darwin going forward is a DWARF platform, so, shouldn't be a heartache for real folks. agreed, in fact the default for current assemblers doesn’t support stabs - and we’ve adjusted the specs to deal with that. > For ancient machines, ancient compilers might be a requirement. Generally, I like keeping things; but cleanups and removals are a part of life, and eventually the old should be removed. I'd not stand in the way of such removal. If we were within 5 years of such a transition point, I'd argue to keep it for at least 5 years. But, the switch for darwin was Oct 26th, 2007. 10 years I think is a nice cutover point for first tier things. Beyond 10, and I'd say, you are dragging your feet. If _all_ the code for DBX were in my port file, I'd be tempted to keep it indefinitely. It's not, so, that's not possible/reasonable. > > Iain, do you still have the G5s? :-) Do they run 8 or 9? What do you think? Seem reasonable? I still have access to i686 and powerpc Darwin8, but testing is extremely infrequent. For the record; anyone wanting modern toolchains on Darwin8 most likely has to face building a linker and more modern cctools anyway(the XCode 2.5 set was extremely flaky from at least 4.6/4.7). I’d suspect that a person serious in doing that would likely be willing to build GDB which does support x86 Darwin, at least. FWIW I have a patch that makes GDB (at least 7.x) work for PowerPC too. If anyone cares, ask ;-) (I doubt if I’ll try modernising it across the transition to c++ for GDB - since available time would prob be better spent elsewhere). Anyone wanting to build modern GCC on < Darwin8 is going to need to build most of the supporting infra too - the (XCode 1.5) linker/assembler there don’t support enough weak stuff to be viable for modern c++. These very old platforms are long past the “config && make” stage, supporting them needs a degree of commitment and understanding. ----- My G5 ( and most of my other ppc hardware) habitually runs 10.5 (Darwin9) and I’ve no motivation to reboot to 10.4 unless to test something more quickly than my really ancient G4s can manage. > The 64_BIT x86 darwin question likely can be be flipped to default to dwarf; so, even that isn't an issue. It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime. cheers, Iain Iain Sandoe CodeSourcery / Mentor Embedded
On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe <iain@codesourcery.com> wrote:
> It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime.
Yes, they do default to dwarf2. The comments say pre-darwin9 32-bit
defaults to stabs. The question is whether anyone cares about that
anymore.
Jim
> On 21 Jul 2017, at 20:54, Jim Wilson <jim.wilson@linaro.org> wrote: > > On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe <iain@codesourcery.com> wrote: >> It ought to be already, in fact anything (powerpc*/x86/x86-64) >= Darwin9 (OS X 10.5) ought to be defaulting to DWARF already, will check that sometime. > > Yes, they do default to dwarf2. The comments say pre-darwin9 32-bit > defaults to stabs. The question is whether anyone cares about that > anymore. From my perspective, as per Mike’s comments, I’d say “let’s move on”, - Darwin8’s DWARF support is good enough for C at least - as per my other comments, there remain ways forward for someone who really wants to support it (TenFourFox seems still active and I do get a few queries per year from folks working with Darwin8). - deprecation gives other folks a chance to shout if they care. cheers Iain Iain Sandoe CodeSourcery / Mentor Embedded
On 07/21/2017 01:07 PM, Nathan Sidwell wrote: > [darwin, cygwin, rx maintainers, you might have an opinion] > Let's at least deprecate it. I attach a patch to do so. With the > patch, you'll get a note about dbx being deprecated whenever you use > stabs debugging on a system that prefers stabs (thus both -g and -gstabs > will warn). On systems where stabs is not preferred, -gstabs will not > give you a warning. The patch survices an x86_64-linux bootstrap. > > A config can chose to override thus by defining 'DBX_DEBUG_OK' in the > build defines. > > I did try build time CPP tricks, but config/rx.h and > config/i386/darwin.h define it to be a conditional expression. > > AFAICT, the following include files are not used, and could probably be > binned too: > config/dbx.h > config/dbxcoff.h > config/dbxelf.h > (+ configi386/gstabs.h Jim found) > > It looks like DBX is the default for: > i386/cygming configured for 32-bit or lacking PE_SECREL32_RELOC > i386/darwin.h for 32-bit target > rx/rx.h when using AS100 syntax > > nathan Cygwin GCC has been using --with-dwarf2 for sometime now, so it shouldn't be affected.
2017-07-21 Nathan Sidwell <nathan@acm.org> * toplev.c (process_options): Warn about DBX being deprecated. Index: toplev.c =================================================================== --- toplev.c (revision 250424) +++ toplev.c (working copy) @@ -1413,6 +1413,12 @@ process_options (void) debug_info_level = DINFO_LEVEL_NONE; } +#ifndef DBX_DEBBUG_OK + if (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG + && write_symbols == DBX_DEBUG) + inform (UNKNOWN_LOCATION, "DBX (stabs) debugging is deprecated"); +#endif + if (flag_dump_final_insns && !flag_syntax_only && !no_backend) { FILE *final_output = fopen (flag_dump_final_insns, "w");