[PATCH] Fix hot/cold partitioning with -gstabs{,+} (PR debug/81307)

[Jim Wilson]

On 11/27/2017 12:21 AM, Richard Biener wrote:
> Let's formally deprecate any non-DWARF debugging format support
> in GCC 8 changes.html?

I think we need to be careful about that.  I've been looking at the 
stabs support after I finished removing the sdb/coff debug info support. 
  We have 3 cpu targets that only support stabs (avr, pdp11, vax).  We 
have two OS targets that only support stabs, though in both cases the 
cpus do support dwarf and hence they could switch.  We have two embedded 
targets that support the --with-stabs configure option.  We have a few 
targets that might default to stabs if used with old obsolete assembler 
versions that probably don't work anymore anyways.  And we have AIX 
which continues to use XCOFF_DEBUG which is a variant of stabs, and 
shares some of the same code.  We also have vms which apparently uses a 
mixture of vms and dwarf2 debugging.  Does that count as a non-DWARF 
debugging format?

I think a good first step would be to emit a compile-time warning if gcc 
was configured to emit stabs by default.  E.g. maybe something like
#if PREFERRED_DEBUGGING_TYPE == DBX_DEBUG
#warning "dbx/stabs debug info support is being deprecated"
#endif
in a popular header file.  That gives maintainers a chance to fix their 
ports.  I was planning to propose this after gcc-8, but we could maybe 
add it to gcc-8.  Then maybe in the next version this changes to a 
#error, so you can't build a gcc that emits stabs by default, but users 
can still get stabs with -gstabs.  We can then emit a run-time warning 
when a user uses -gstabs, and then later a run-time error when -gstabs 
is used.  That gives users a chance to migrate before it breaks.  Then 
we can remove -gstabs, careful to avoid breaking xcoff support, until 
IBM agrees in the futility of continuing to maintain it and lets us 
remove xcoff too.

Jim