https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81733
--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #8) > (In reply to Iain Sandoe from comment #7) > > (In reply to Iain Sandoe from comment #6) > > > (In reply to Iain Sandoe from comment #5) > > > > (In reply to Iain Sandoe from comment #4) > > > > > (In reply to r...@cebitec.uni-bielefeld.de from comment #3) > > > > > > > --- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> --- > > > some of the verify fails seem to be caused by the ancient dwarfdump not > > > being smart enough; ld64 and BINUTILS objdump seem to be happy that the > > > FDEs > > > are well-formed (more checking to be done) With "more modern" cctools and ld64 this sub-set still fails dwarfdump --eh --verify (for x86-64). These do seem to be spurious and caused by dwarfdump not dealing with the relocations for the start symbols in the eh_frame. For these cases, ld64, BINUTILS objdump and LLVM objdump are all happy that the FDEs are correctly formed - so (a) they don't seem to be a problem and (b) the m64 unwinder should never be used on any Darwin >= 10 anyway.
