Re: Deprecate DBX/stabs?

[Richard Biener]

On Fri, Jul 21, 2017 at 4:15 PM, David Edelsohn  wrote:
>> Nathan Sidwell writes:
>
>> 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.
>
> Absolutely not.
>
> AIX still uses DBX as the primary debugging format.  AIX supports
> DWARF but the AIX toolchain does not fully interoperate with DWARF
> generated by GCC.
>
> With the extensive use of DBX by AIX and regular patches from me to
> fix xcoff stabs debugging, omitting me from the cc list implies that
> you really haven't done your homework.

The proposal was to define DBX_DEBUG_OK on such targets so their
users do not get the deprecation warning.

The idea is to remove support for STABS from targets that have well
established DWARF support (like xyz-linux).

Of course I would like complete STABS deprecation more but I knew
that at least AIX stands in the way here ;)

Richard.


> Thanks, David

Re: Deprecate DBX/stabs?

[JonY]

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.



signature.asc
Description: OpenPGP digital signature

Re: Deprecate DBX/stabs?

[Iain Sandoe]

> On 21 Jul 2017, at 20:54, Jim Wilson  wrote:
> 
> On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe  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

Re: Deprecate DBX/stabs?

[Jim Wilson]

On Fri, Jul 21, 2017 at 12:44 PM, Iain Sandoe  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

Re: Deprecate DBX/stabs?

[Iain Sandoe]

> On 21 Jul 2017, at 20:10, Mike Stump  wrote:
> 
> On Jul 21, 2017, at 6:07 AM, Nathan Sidwell  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

Re: Deprecate DBX/stabs?

[Mike Stump]

On Jul 21, 2017, at 9:03 AM, Jim Wilson  wrote:
> There is also the matter of SDB_DEBUG which is still supported, and is
> no longer used by anyone, as we have already deprecated all of the
> COFF targets that were using it.  SDB support for C++ is even worse
> than the DBX support.  This should be no problem to deprecate and
> remove.  We could perhaps even just drop it without bothering to
> deprecate it first.

I think that's reasonable.  I haven't used adb and sdb in years.  :-)

Re: Deprecate DBX/stabs?

[Mike Stump]

On Jul 21, 2017, at 6:07 AM, Nathan Sidwell  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.

Re: Deprecate DBX/stabs?

[Jim Wilson]

On Fri, Jul 21, 2017 at 7:15 AM, David Edelsohn  wrote:
> AIX still uses DBX as the primary debugging format.  AIX supports
> DWARF but the AIX toolchain does not fully interoperate with DWARF
> generated by GCC.

We could still deprecate DBX_DEBUG while leaving XCOFF_DEBUG alone for
now.  This would encourage people to migrate to DWARF2.  We won't be
able to drop dbxout.c until both DBX_DEBUG and XCOFF_DEBUG are dropped
which could be a while, but we can perhaps avoid any new users of
stabs.

I see that avr-*, *-lynx, pre-darwin9 32-bit i686-darwin, *-openbsd,
pdp11-*, vax-*, and cygwin/mingw32 with obsolete assemblers still
default to DBX_DEBUG.  Some of those can be dropped, and the others
can migrate to dwarf.

There is also the matter of SDB_DEBUG which is still supported, and is
no longer used by anyone, as we have already deprecated all of the
COFF targets that were using it.  SDB support for C++ is even worse
than the DBX support.  This should be no problem to deprecate and
remove.  We could perhaps even just drop it without bothering to
deprecate it first.

Jim

Re: Deprecate DBX/stabs?

[David Edelsohn]

> Nathan Sidwell writes:

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

Absolutely not.

AIX still uses DBX as the primary debugging format.  AIX supports
DWARF but the AIX toolchain does not fully interoperate with DWARF
generated by GCC.

With the extensive use of DBX by AIX and regular patches from me to
fix xcoff stabs debugging, omitting me from the cc list implies that
you really haven't done your homework.

Thanks, David

Re: Deprecate DBX/stabs?

[Nathan Sidwell]

On 07/21/2017 09:16 AM, Richard Biener wrote:

On Fri, Jul 21, 2017 at 3:07 PM, Nathan Sidwell  wrote:



+#ifndef DBX_DEBBUG_OK
 ^^^
typo?  The patch doesn't define this anywhere - I suggest to add it to
defaults.h
as 0 and use #if?  Also would need documenting if this is supposed to be a
target macro.


Like this?  I've now included XCOFF, as it's a subset of DBX.  Nothing 
appears to default to it.


nathan
--
Nathan Sidwell
2017-07-21  Nathan Sidwell  

	* defaults.h (DBX_DEBUG_DEPRECATED): New.
	* toplev.c (process_options): Warn about DBX/SDB being deprecated.
	* doc/tm.texi.in (DBX_DEBUG_DEPRECATED): Document.
	* doc/tm.texi: Updated.

Index: defaults.h
===
--- defaults.h	(revision 250426)
+++ defaults.h	(working copy)
@@ -889,6 +889,12 @@ see the files COPYING3 and COPYING.RUNTI
 #define SDB_DEBUGGING_INFO 0
 #endif
 
+/* DBX debugging is deprecated, and will generate a note if you
+   default to it.  */
+#ifndef DBX_DEBUG_DEPRECATED
+#define DBX_DEBUG_DEPRECATED 1
+#endif
+
 /* If more than one debugging type is supported, you must define
PREFERRED_DEBUGGING_TYPE to choose the default.  */
 
Index: doc/tm.texi
===
--- doc/tm.texi	(revision 250426)
+++ doc/tm.texi	(working copy)
@@ -9553,6 +9553,14 @@ user can always get a specific type of o
 
 @c prevent bad page break with this line
 These are specific options for DBX output.
+DBX debug data is deprecated and is expected to be removed.
+
+@defmac DBX_DEBUG_DEPRECATED
+Defined this macro to 1 if GCC should not warn about defaulting to DBX
+or XCOFF debug output.  This is intended to give maintainers notice of
+deprecation, but not be unnecessarily invasive.  Defining this macro is
+a short-term measure.  You need to plan for DBX's removal.
+@end defmac
 
 @defmac DBX_DEBUGGING_INFO
 Define this macro if GCC should produce debugging output for DBX
Index: doc/tm.texi.in
===
--- doc/tm.texi.in	(revision 250426)
+++ doc/tm.texi.in	(working copy)
@@ -6842,6 +6842,14 @@ user can always get a specific type of o
 
 @c prevent bad page break with this line
 These are specific options for DBX output.
+DBX debug data is deprecated and is expected to be removed.
+
+@defmac DBX_DEBUG_DEPRECATED
+Defined this macro to 1 if GCC should not warn about defaulting to DBX
+or XCOFF debug output.  This is intended to give maintainers notice of
+deprecation, but not be unnecessarily invasive.  Defining this macro is
+a short-term measure.  You need to plan for DBX's removal.
+@end defmac
 
 @defmac DBX_DEBUGGING_INFO
 Define this macro if GCC should produce debugging output for DBX
Index: toplev.c
===
--- toplev.c	(revision 250426)
+++ toplev.c	(working copy)
@@ -1413,6 +1413,12 @@ process_options (void)
 	debug_info_level = DINFO_LEVEL_NONE;
 }
 
+  if (DBX_DEBUG_DEPRECATED
+  && write_symbols == PREFERRED_DEBUGGING_TYPE
+  && (PREFERRED_DEBUGGING_TYPE == DBX_DEBUG
+	  || PREFERRED_DEBUGGING_TYPE == XCOFF_DEBUG))
+inform (UNKNOWN_LOCATION, "DBX/XCOFF (stabs) debugging is deprecated");
+
   if (flag_dump_final_insns && !flag_syntax_only && !no_backend)
 {
   FILE *final_output = fopen (flag_dump_final_insns, "w");

Re: Deprecate DBX/stabs?

[Richard Biener]

On Fri, Jul 21, 2017 at 3:07 PM, Nathan Sidwell  wrote:
> [darwin, cygwin, rx maintainers, you might have an opinion]
>
> On 07/21/2017 01:11 AM, Richard Biener wrote:
>>
>> On July 21, 2017 12:03:58 AM GMT+02:00, Jim Wilson 
>> wrote:
>>>
>>> On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell  wrote:

 With this patch the gdb stabs test results are still awful, but they
>>>
>>> are

 unchanged awfulness.
>>>
>>>
>>> Anyways, your new dbxout.c patch looks good.  And maybe we should
>>> think about deprecating the stabs support some day.
>>
>>
>> I've suggested that multiple times also to be able to get rid of the debug
>> hook interfacing in GCC and emit dwarf directly from FEs where that makes
>> sense.  DWARF should be a superset of other debug formats so it should be
>> possible to build stabs from dwarf.
>
>
> 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

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
^^^
typo?  The patch doesn't define this anywhere - I suggest to add it to
defaults.h
as 0 and use #if?  Also would need documenting if this is supposed to be a
target macro.

Thanks,
Richard.

> nathan
> --
> Nathan Sidwell

Deprecate DBX/stabs?

[Nathan Sidwell]

[darwin, cygwin, rx maintainers, you might have an opinion]

On 07/21/2017 01:11 AM, Richard Biener wrote:

On July 21, 2017 12:03:58 AM GMT+02:00, Jim Wilson  
wrote:

On Thu, Jul 20, 2017 at 2:00 PM, Nathan Sidwell  wrote:

With this patch the gdb stabs test results are still awful, but they

are

unchanged awfulness.


Anyways, your new dbxout.c patch looks good.  And maybe we should
think about deprecating the stabs support some day.


I've suggested that multiple times also to be able to get rid of the debug hook 
interfacing in GCC and emit dwarf directly from FEs where that makes sense.  
DWARF should be a superset of other debug formats so it should be possible to 
build stabs from dwarf.


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
--
Nathan Sidwell
2017-07-21  Nathan Sidwell  

	* 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");