This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Mon, 27 Nov 2017, Jim Wilson wrote:

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

I think we want to decomission -gstabs for all targets that do not
default to it (or variants of it) and adjust documentation to
reflect that -gstabs is unmaintained and deprecated.  We also want to
deprecate --with-stabs if there is an alternative, preferable emit
a warning for this configure option for GCC 8 and remove support for GCC 9.

I think embedded folks stick to STABS because of its smaller size, not
because it is anywhere useful.

Richard.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]