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
