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.
