[Bug ada/81361] [8 regression] broken exception handling at -O2
iains at gcc dot gnu.org
Fri Sep 15 15:06:00 GMT 2017
--- 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
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.
More information about the Gcc-bugs