[Bug ada/81361] [8 regression] broken exception handling at -O2

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81361

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Eric Botcazou from comment #12)
> > Bootstrap completed on Darwin with the tentative fix (and the workaround for
> > PR target/80556) and the ACATS testsuite is clean.
> 
> Also, doing a bootstrap on D15.6 with the patch and the
> --with-xxxx-ldflags=-static-libstdc++.

works for me too.

> So, FAOD, the fix is a work-around for a bug in either the assembler or
> unwinder? (the original DWARF output is expected to be well-formed?)
> 
> Given that the GCC unwinder segvs in the same place, perhaps it's more
> likely an assembler issue.  Are you using LLVM-backend-based assembler (i.e.
> via clang) and, if so, what version?  Like GCC the DWARF code is mostly
> common in LLVM, so we should raise an upstream bug report + a radar.
> 
> it could be interesting to compare as -q ... with as -Q to see if the bug is
> also present in the GAS-based assembler .. dwarfdump --verify and --eh-frame
> could be interesting too.

I did this and there's nothing interesting revealed - everything consistently
gives the same output (and dwarfdump --verify claims it's valid).

There's one point that I'm pursuing, which is that some relocations are elided
from mach-o objects, where the linker can figure out the right result without
needing one.  So it could be an oversight, or a ld64 bug too.  Since Darwin is
now using .cfi_xxxx there's probably not much testing of the DWARF stuff
outside GCC use.

I also have some patches to enable .cfi_xxxx in Darwin GCC, but need to rebase
them to current trunk.  I guess the hard thing at the moment is to know what
the true intention  was and therefore which component is buggy.