[v2] Always default to DWARF2_DEBUG if not specified, warn about deprecated STABS

  This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
is not specified by the target and NO_DEBUG if DWARF is not supported.

It also makes us warn when STABS is enabled and removes the corresponding
diagnostic from the Ada frontend.  The warnings are pruned from the
testsuite output via prune_gcc_output.

This leaves the following targets without debug support:

 pdp11-*-*   pdp11 is a.out, dwarf support is difficult
 m68k*-*-openbsd*  it looks like this is a.out as well, at least it does
                   not pretend to support DWARF
 hppa[12]*-*-hpux10*  does seem to not support DWARF
 vax-*-openbsd*  seems to be a.out as well, does not support DWARF

behavior will be like

> ./cc1 -quiet t.c -g
cc1: warning: target system does not support debug output
> ./cc1 -quiet t.c -gstabs
t.c: warning: STABS debugging information is obsolete and not supported anymore

that is, -g is unsupported but -gstabs will generate STABS (the above
is for pdp11).  It would be nice if maintainers could confirm the above
listed configurations do not support DWARF and weight in whether to
(apart from pdp11) the specific configurations can be obsoleted or
adjusted.  It looks like we do not have any openbsd maintainer.
I've discussed the situation for pdp11 with Paul already at some point
but we didn't reach any conclusion besides that it would be nice to
move pdp11 to ELF.


2021-09-10  Richard Biener  <rguenther@suse.de>

gcc/
	* defaults.h (PREFERRED_DEBUGGING_TYPE): Choose DWARF2_DEBUG
	or NO_DEBUG.
	* toplev.c (process_options): Warn when STABS debugging is
	enabled.

gcc/ada/
	* gcc-interface/misc.c (gnat_post_options): Do not warn
	about DBX_DEBUG use here.

gcc/testsuite/
	* lib/prune.exp: Prune STABS obsoletion message.
---
 gcc/ada/gcc-interface/misc.c |  6 ------
 gcc/defaults.h               | 27 ++++-----------------------
 gcc/testsuite/lib/prune.exp  |  3 +++
 gcc/toplev.c                 |  5 +++++
 4 files changed, 12 insertions(+), 29 deletions(-)
  

On 9/13/2021 1:31 AM, Richard Biener wrote:
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
>
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic from the Ada frontend.  The warnings are pruned from the
> testsuite output via prune_gcc_output.
>
> This leaves the following targets without debug support:
>
>   pdp11-*-*   pdp11 is a.out, dwarf support is difficult
>   m68k*-*-openbsd*  it looks like this is a.out as well, at least it does
>                     not pretend to support DWARF
>   hppa[12]*-*-hpux10*  does seem to not support DWARF
I would probably argue that hpux10 should just be removed, along with 
hpux 7-9 if they haven't been already.  It's the epitome of a dead platform.


>   vax-*-openbsd*  seems to be a.out as well, does not support DWARF
>
> behavior will be like
>
>> ./cc1 -quiet t.c -g
> cc1: warning: target system does not support debug output
>> ./cc1 -quiet t.c -gstabs
> t.c: warning: STABS debugging information is obsolete and not supported anymore
>
> that is, -g is unsupported but -gstabs will generate STABS (the above
> is for pdp11).  It would be nice if maintainers could confirm the above
> listed configurations do not support DWARF and weight in whether to
> (apart from pdp11) the specific configurations can be obsoleted or
> adjusted.  It looks like we do not have any openbsd maintainer.
> I've discussed the situation for pdp11 with Paul already at some point
> but we didn't reach any conclusion besides that it would be nice to
> move pdp11 to ELF.
>
>
> 2021-09-10  Richard Biener  <rguenther@suse.de>
>
> gcc/
> 	* defaults.h (PREFERRED_DEBUGGING_TYPE): Choose DWARF2_DEBUG
> 	or NO_DEBUG.
> 	* toplev.c (process_options): Warn when STABS debugging is
> 	enabled.
>
> gcc/ada/
> 	* gcc-interface/misc.c (gnat_post_options): Do not warn
> 	about DBX_DEBUG use here.
>
> gcc/testsuite/
> 	* lib/prune.exp: Prune STABS obsoletion message.
OK
jeff
  

On Mon, 13 Sep 2021, Jeff Law wrote:

> 
> 
> On 9/13/2021 1:31 AM, Richard Biener wrote:
> > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > is not specified by the target and NO_DEBUG if DWARF is not supported.
> >
> > It also makes us warn when STABS is enabled and removes the corresponding
> > diagnostic from the Ada frontend.  The warnings are pruned from the
> > testsuite output via prune_gcc_output.
> >
> > This leaves the following targets without debug support:
> >
> >   pdp11-*-*   pdp11 is a.out, dwarf support is difficult
> >   m68k*-*-openbsd*  it looks like this is a.out as well, at least it does
> >                     not pretend to support DWARF
> >   hppa[12]*-*-hpux10*  does seem to not support DWARF
> I would probably argue that hpux10 should just be removed, along with hpux 7-9
> if they haven't been already.  It's the epitome of a dead platform.

It is in fact also hpux11*, thus all 32bit pa configs that do not support
DWARF (for whatever reasons).

Richard.

> 
> >   vax-*-openbsd*  seems to be a.out as well, does not support DWARF
> >
> > behavior will be like
> >
> >> ./cc1 -quiet t.c -g
> > cc1: warning: target system does not support debug output
> >> ./cc1 -quiet t.c -gstabs
> > t.c: warning: STABS debugging information is obsolete and not supported
> > anymore
> >
> > that is, -g is unsupported but -gstabs will generate STABS (the above
> > is for pdp11).  It would be nice if maintainers could confirm the above
> > listed configurations do not support DWARF and weight in whether to
> > (apart from pdp11) the specific configurations can be obsoleted or
> > adjusted.  It looks like we do not have any openbsd maintainer.
> > I've discussed the situation for pdp11 with Paul already at some point
> > but we didn't reach any conclusion besides that it would be nice to
> > move pdp11 to ELF.
> >
> >
> > 2021-09-10  Richard Biener  <rguenther@suse.de>
> >
> > gcc/
> >  * defaults.h (PREFERRED_DEBUGGING_TYPE): Choose DWARF2_DEBUG
> >  or NO_DEBUG.
> >  * toplev.c (process_options): Warn when STABS debugging is
> >  enabled.
> >
> > gcc/ada/
> >  * gcc-interface/misc.c (gnat_post_options): Do not warn
> >  about DBX_DEBUG use here.
> >
> > gcc/testsuite/
> >  * lib/prune.exp: Prune STABS obsoletion message.
> OK
> jeff
> 
> 
>
  

On 9/13/2021 7:47 AM, Richard Biener wrote:
> On Mon, 13 Sep 2021, Jeff Law wrote:
>
>>
>> On 9/13/2021 1:31 AM, Richard Biener wrote:
>>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>>> is not specified by the target and NO_DEBUG if DWARF is not supported.
>>>
>>> It also makes us warn when STABS is enabled and removes the corresponding
>>> diagnostic from the Ada frontend.  The warnings are pruned from the
>>> testsuite output via prune_gcc_output.
>>>
>>> This leaves the following targets without debug support:
>>>
>>>    pdp11-*-*   pdp11 is a.out, dwarf support is difficult
>>>    m68k*-*-openbsd*  it looks like this is a.out as well, at least it does
>>>                      not pretend to support DWARF
>>>    hppa[12]*-*-hpux10*  does seem to not support DWARF
>> I would probably argue that hpux10 should just be removed, along with hpux 7-9
>> if they haven't been already.  It's the epitome of a dead platform.
> It is in fact also hpux11*, thus all 32bit pa configs that do not support
> DWARF (for whatever reasons).
We used embedded stabs for SOM (the native format for 32bit PA). SOM is 
a variant of COFF and could easily support dwarf I would think since it 
had support for fairly arbitrary sections.  Hell, it was already 
supporting embedded stabs as well as HP's proprietary debugging format.

But I'd consider 32bit SOM on hpux11 dead too :-)  I nearly asked why 
you restricted your original comment to hpux10...

Jeff
  

On 2021-09-13 9:53 a.m., Jeff Law wrote:
>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>> DWARF (for whatever reasons).
> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
>
> But I'd consider 32bit SOM on hpux11 dead too :-)
I don't disagree but 32bit SOM still builds on hpux11:
https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html

Suspect the change will cause a lot of warnings.

There is some support for hpux10/11 in qemu but it takes a lot of work to provide the build infrastructure
needed for gcc.

DWARF isn't supported because we lack named sections.  That could be worked around
but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.

Dave
  

On 9/13/2021 8:58 AM, John David Anglin wrote:
> On 2021-09-13 9:53 a.m., Jeff Law wrote:
>>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>>> DWARF (for whatever reasons).
>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
>> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
>>
>> But I'd consider 32bit SOM on hpux11 dead too :-)
> I don't disagree but 32bit SOM still builds on hpux11:
> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html
>
> Suspect the change will cause a lot of warnings.
It might, but with stabs going away something needs to be done with 
these legacy systems.  Either they need to move into the modern world, 
deal with the diagnostic  or get dropped.

>
> There is some support for hpux10/11 in qemu but it takes a lot of work to provide the build infrastructure needed for gcc.
I would think so.

>
> DWARF isn't supported because we lack named sections.  That could be worked around
> but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.
I'd be a bit surprised if that were true.  dwarf support has been around 
a long long time in GDB.  Hell, it was around when I did the original 
64bit PA work back in the 90s.

Jeff
  

On 2021-09-13 11:05 a.m., Jeff Law wrote:
>
>
> On 9/13/2021 8:58 AM, John David Anglin wrote:
>> On 2021-09-13 9:53 a.m., Jeff Law wrote:
>>>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>>>> DWARF (for whatever reasons).
>>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
>>> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
>>>
>>> But I'd consider 32bit SOM on hpux11 dead too :-)
>> I don't disagree but 32bit SOM still builds on hpux11:
>> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html
>>
>> Suspect the change will cause a lot of warnings.
> It might, but with stabs going away something needs to be done with these legacy systems.  Either they need to move into the modern world,
> deal with the diagnostic  or get dropped.
I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
The current versions should suffice for several years.

My main interest is the Debian parisc-linux target.  It's fully up to date and thousands of packages are available.  Most kernels are 64-bit.
Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing.
>
>>
>> There is some support for hpux10/11 in qemu but it takes a lot of work to provide the build infrastructure needed for gcc.
> I would think so.
Recently had to move my build infrastructure to a "new" machine, so I'm fully aware that it's not easy.
>
>>
>> DWARF isn't supported because we lack named sections.  That could be worked around
>> but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.
> I'd be a bit surprised if that were true.  dwarf support has been around a long long time in GDB.  Hell, it was around when I did the original
> 64bit PA work back in the 90s.
There's a chance it might work with the right section names.  However dwarf 5 wouldn't be supported.  That's an
issue that I noticed recently.

Dave
  

On 9/13/2021 9:44 AM, John David Anglin wrote:
> On 2021-09-13 11:05 a.m., Jeff Law wrote:
>>
>> On 9/13/2021 8:58 AM, John David Anglin wrote:
>>> On 2021-09-13 9:53 a.m., Jeff Law wrote:
>>>>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
>>>>> DWARF (for whatever reasons).
>>>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
>>>> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
>>>>
>>>> But I'd consider 32bit SOM on hpux11 dead too :-)
>>> I don't disagree but 32bit SOM still builds on hpux11:
>>> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html
>>>
>>> Suspect the change will cause a lot of warnings.
>> It might, but with stabs going away something needs to be done with these legacy systems.  Either they need to move into the modern world,
>> deal with the diagnostic  or get dropped.
> I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
> The current versions should suffice for several years.
Seems quite reasonable.

>
> My main interest is the Debian parisc-linux target.  It's fully up to date and thousands of packages are available.  Most kernels are 64-bit.
> Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing.
Agreed.  Given that the 32bit linux and 64bit hpux targets both use ELF 
+ dwarf, they're not in danger of significant fallout from the stabs 
removal effort.
>
>>> DWARF isn't supported because we lack named sections.  That could be worked around
>>> but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.
>> I'd be a bit surprised if that were true.  dwarf support has been around a long long time in GDB.  Hell, it was around when I did the original
>> 64bit PA work back in the 90s.
> There's a chance it might work with the right section names.  However dwarf 5 wouldn't be supported.  That's an issue that I noticed recently.
Yea, without a modern gdb, 32bit SOM would be stuck back in the dwarf2 
era.  But even that's better than embedded stabs.

jeff
  

> On Sep 13, 2021, at 3:31 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.
> 
> It also makes us warn when STABS is enabled and removes the corresponding
> diagnostic from the Ada frontend.  The warnings are pruned from the
> testsuite output via prune_gcc_output.
> 
> This leaves the following targets without debug support:
> 
> pdp11-*-*   pdp11 is a.out, dwarf support is difficult

I'll admit that I don't know much about debug formats.  It is definitely the case that pdp11 output is a.out (it may be BSD 2.x style a.out -- which I think is somewhat different though it's been many years since I looked at that, and then only briefly).  I guess that constrains which debug formats can be used, but I don't know any details.

pdp11-elf was done as an experiment by someone else, in binutils.  I'll ask about the status of that.  If it's possible to deliver that, it would presumably enable DWARF support.  Is that all common code so it's a matter of enabling it, or would "DWARF machine details for pdp11" have to be defined?

	paul
  

On 9/13/2021 10:52 AM, Koning, Paul wrote:
>
>> On Sep 13, 2021, at 3:31 AM, Richard Biener <rguenther@suse.de> wrote:
>>
>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>> is not specified by the target and NO_DEBUG if DWARF is not supported.
>>
>> It also makes us warn when STABS is enabled and removes the corresponding
>> diagnostic from the Ada frontend.  The warnings are pruned from the
>> testsuite output via prune_gcc_output.
>>
>> This leaves the following targets without debug support:
>>
>> pdp11-*-*   pdp11 is a.out, dwarf support is difficult
> I'll admit that I don't know much about debug formats.  It is definitely the case that pdp11 output is a.out (it may be BSD 2.x style a.out -- which I think is somewhat different though it's been many years since I looked at that, and then only briefly).  I guess that constrains which debug formats can be used, but I don't know any details.
My recollection of aout stabs is mostly lost.  IIRC we'd emit .stabs 
directives to the assembler which would turn into symbol table entries.

Embedded stabs used the same underlying stab strings, but instead put 
the information into a special section.  That requires an object format 
that supports named sections, so it's a non-starter for a.out.

dwarf also requires named sections.  While in theory one could probably 
do something hackish like dwarf embedded in .stab directives, that just 
seems just awful.

>
> pdp11-elf was done as an experiment by someone else, in binutils.  I'll ask about the status of that.  If it's possible to deliver that, it would presumably enable DWARF support.  Is that all common code so it's a matter of enabling it, or would "DWARF machine details for pdp11" have to be defined?
That's going to be the best path forward.  Get the pdp11-elf bits 
working and the dwarf2 debugging stuff should come along for free.

Jeff
  

On Mon, 13 Sep 2021, John David Anglin wrote:

> On 2021-09-13 11:05 a.m., Jeff Law wrote:
> >
> >
> > On 9/13/2021 8:58 AM, John David Anglin wrote:
> >> On 2021-09-13 9:53 a.m., Jeff Law wrote:
> >>>> It is in fact also hpux11*, thus all 32bit pa configs that do not support
> >>>> DWARF (for whatever reasons).
> >>> We used embedded stabs for SOM (the native format for 32bit PA). SOM is a variant of COFF and could easily support dwarf I would think since
> >>> it had support for fairly arbitrary sections.  Hell, it was already supporting embedded stabs as well as HP's proprietary debugging format.
> >>>
> >>> But I'd consider 32bit SOM on hpux11 dead too :-)
> >> I don't disagree but 32bit SOM still builds on hpux11:
> >> https://gcc.gnu.org/pipermail/gcc-testresults/2021-August/718130.html
> >>
> >> Suspect the change will cause a lot of warnings.
> > It might, but with stabs going away something needs to be done with these legacy systems.  Either they need to move into the modern world,
> > deal with the diagnostic  or get dropped.
> I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
> The current versions should suffice for several years.

Do you think it's worth keeping the 32bit pa hpux targets for another
release but guarded with --enable-obsolete or can we remove those
configurations right away?

In the current setting configurations that do not support DWARF will
get no debug info with -g (with a warning that this happens) and
STABS debug info with -gstabs (with a warning about its deprecation).
That might not be the final outcome for GCC 12 but it's the minimal
change I'm working towards.

> My main interest is the Debian parisc-linux target.  It's fully up to date and thousands of packages are available.  Most kernels are 64-bit.
> Since there's no 64-bit runtime for Linux, we still need the 64-bit hpux target for 64-bit compile testing.

The 64bit pa configs seem to support DWARF so they are fine, correct,
it's only 32bit hpux configs that we'll leave behind.

Richard.

> >
> >>
> >> There is some support for hpux10/11 in qemu but it takes a lot of work to provide the build infrastructure needed for gcc.
> > I would think so.
> Recently had to move my build infrastructure to a "new" machine, so I'm fully aware that it's not easy.
> >
> >>
> >> DWARF isn't supported because we lack named sections.  That could be worked around
> >> but probably the gdb versions that work on 32-bit hpux11 wouldn't support DWARF.
> > I'd be a bit surprised if that were true.  dwarf support has been around a long long time in GDB.  Hell, it was around when I did the original
> > 64bit PA work back in the 90s.
> There's a chance it might work with the right section names.  However dwarf 5 wouldn't be supported.  That's an
> issue that I noticed recently.
  

On 2021-09-15 2:26 a.m., Richard Biener wrote:
>> I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
>> The current versions should suffice for several years.
> Do you think it's worth keeping the 32bit pa hpux targets for another
> release but guarded with --enable-obsolete or can we remove those
> configurations right away?
I would choose --enable-obsolete.  Currently, things more or less work except for modules.
>
> In the current setting configurations that do not support DWARF will
> get no debug info with -g (with a warning that this happens) and
> STABS debug info with -gstabs (with a warning about its deprecation).
> That might not be the final outcome for GCC 12 but it's the minimal
> change I'm working towards.
Is there a simple way to enable -gstabs in build?

Dave
  

On Wed, 15 Sep 2021, John David Anglin wrote:

> On 2021-09-15 2:26 a.m., Richard Biener wrote:
> >> I believe the 32-bit SOM target should be deprecated.  I'm the only one maintaining it and I had some health issues earlier this year.
> >> The current versions should suffice for several years.
> > Do you think it's worth keeping the 32bit pa hpux targets for another
> > release but guarded with --enable-obsolete or can we remove those
> > configurations right away?
> I would choose --enable-obsolete.  Currently, things more or less work except for modules.

OK, I see.

> >
> > In the current setting configurations that do not support DWARF will
> > get no debug info with -g (with a warning that this happens) and
> > STABS debug info with -gstabs (with a warning about its deprecation).
> > That might not be the final outcome for GCC 12 but it's the minimal
> > change I'm working towards.
> Is there a simple way to enable -gstabs in build?

Currently not.  If we're retaining more than pdp11 with a non-DWARF
config I'm considering to allow STABS by default for those without
diagnostics for GCC 12.

With GCC 13 we'll definitely either remove the configurations or
leave the target without any support for debug info.

Richard.
  

On 2021-09-15 10:06 a.m., Richard Biener wrote:
>> Is there a simple way to enable -gstabs in build?
> Currently not.  If we're retaining more than pdp11 with a non-DWARF
> config I'm considering to allow STABS by default for those without
> diagnostics for GCC 12.
>
> With GCC 13 we'll definitely either remove the configurations or
> leave the target without any support for debug info.
I tend to think targets without any support for debug information should be removed.  There is
some time before GCC 13.  This provides a chance for the target to implement DWARF support.

Dave
  

> On Sep 15, 2021, at 11:55 AM, John David Anglin <dave.anglin@bell.net> wrote:
> 
> On 2021-09-15 10:06 a.m., Richard Biener wrote:
>>> Is there a simple way to enable -gstabs in build?
>> Currently not.  If we're retaining more than pdp11 with a non-DWARF
>> config I'm considering to allow STABS by default for those without
>> diagnostics for GCC 12.
>> 
>> With GCC 13 we'll definitely either remove the configurations or
>> leave the target without any support for debug info.
> I tend to think targets without any support for debug information should be removed.  There is
> some time before GCC 13.  This provides a chance for the target to implement DWARF support.

I suppose.  But for pdp11 at least, DWARF and ELF are both somewhat unnatural and anachronistic.  PDP11 unixes use much older debug formats, and DEC operating systems are more primitive still (no debug symbols at all, of any kind).  So for that case at least, supporting the target but without debug symbols would not be a crazy option.

Of course, it would be neat to be able to debug PDP-11 code with GDB...

	paul
  

> On Sep 13, 2021, at 3:31 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> is not specified by the target and NO_DEBUG if DWARF is not supported.

As I'm looking at questions about old debug formats, it brings up the question of old object formats.  I don't remember what the status of a.out is.  Is that considered deprecated?  Still current?  Of course most targets use elf, but is there an expectation to move away from a.out the way there is an expectation to move away from STABS?

Is this actually a binutils rather than a gcc question?

	paul
  

On Wed, 15 Sep 2021, Koning, Paul wrote:

> 
> 
> > On Sep 13, 2021, at 3:31 AM, Richard Biener <rguenther@suse.de> wrote:
> > 
> > This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
> > is not specified by the target and NO_DEBUG if DWARF is not supported.
> 
> As I'm looking at questions about old debug formats, it brings up the 
> question of old object formats.  I don't remember what the status of 
> a.out is.  Is that considered deprecated?  Still current?  Of course 
> most targets use elf, but is there an expectation to move away from 
> a.out the way there is an expectation to move away from STABS?
> 
> Is this actually a binutils rather than a gcc question?

I guess it's a question for both - I do still see a.out targets
in the configs supported by gas for example.

Note that languages like C++ might have difficulties with object
formats that do not support separate sections for instantiated
templates for example, or for global initializers.  We might have
kludges for that in collect2 where removing those might be a
motivation to deprecate object formats not supporting some
set of features (named sections for example).

As for "old", the problem with the legacy systems, being it
pdp11 or hppa-hpux, is of course that they tend to be kept alive
with minimal resources and doing major modernization doesn't
really make sense if all that is wanted is to preserve them
rather than turning them into something modern.

That said - yes, I'd consider a.out purely legacy and not fit
for the future.  But it never came up on the radar of standing
in the way of modernizing GCC in any area.

Richard.
  

On 9/16/2021 1:41 AM, Richard Biener wrote:
> On Wed, 15 Sep 2021, Koning, Paul wrote:
>
>>
>>> On Sep 13, 2021, at 3:31 AM, Richard Biener <rguenther@suse.de> wrote:
>>>
>>> This makes defaults.h choose DWARF2_DEBUG if PREFERRED_DEBUGGING_TYPE
>>> is not specified by the target and NO_DEBUG if DWARF is not supported.
>> As I'm looking at questions about old debug formats, it brings up the
>> question of old object formats.  I don't remember what the status of
>> a.out is.  Is that considered deprecated?  Still current?  Of course
>> most targets use elf, but is there an expectation to move away from
>> a.out the way there is an expectation to move away from STABS?
>>
>> Is this actually a binutils rather than a gcc question?
> I guess it's a question for both - I do still see a.out targets
> in the configs supported by gas for example.
>
> Note that languages like C++ might have difficulties with object
> formats that do not support separate sections for instantiated
> templates for example, or for global initializers.  We might have
> kludges for that in collect2 where removing those might be a
> motivation to deprecate object formats not supporting some
> set of features (named sections for example).
>
> As for "old", the problem with the legacy systems, being it
> pdp11 or hppa-hpux, is of course that they tend to be kept alive
> with minimal resources and doing major modernization doesn't
> really make sense if all that is wanted is to preserve them
> rather than turning them into something modern.
>
> That said - yes, I'd consider a.out purely legacy and not fit
> for the future.  But it never came up on the radar of standing
> in the way of modernizing GCC in any area.
I'd definitely consider a.out & SOM as purely legacy.  As long as they 
continue to work, great, but I wouldn't make any significant investment 
in either.  And yes, there are mechanisms in collect2 to support things 
like global initializers/finalizers on a.out systems.

FWIW, SOM (the 32bit native hpux format) is a COFF derivative and can 
support most of the stuff  ELF can.   Even so, I'd consider it pure legacy.
  

> On Sep 16, 2021, at 11:05 AM, Jeff Law <jeffreyalaw@gmail.com> wrote:
> 
> 
> On 9/16/2021 1:41 AM, Richard Biener wrote:
>> ...
>> That said - yes, I'd consider a.out purely legacy and not fit
>> for the future.  But it never came up on the radar of standing
>> in the way of modernizing GCC in any area.
> I'd definitely consider a.out & SOM as purely legacy.  As long as they continue to work, great, but I wouldn't make any significant investment in either.  And yes, there are mechanisms in collect2 to support things like global initializers/finalizers on a.out systems.

"Legacy" sounds fine.  My main concern was whether it was, or is likely to become soon, "deprecated" or "unsupported".  For an old platform to use legacy formats is perfectly sensible, for it to use deprecated mechanisms is not.

For this to work, if there are no supported debug formats for the object format in question -- which will be the case for a.out with STABS going away -- that would mean you'd get output without debug symbols.  There was a suggestion that this wouldn't be allowed and that it would be grounds for removing such platforms.  I'd rather not see things tied like that.

	paul