https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
--- Comment #9 from Nenad Vukicevic <nenad at intrepid dot com> --- On 11/24/15 12:07 PM, iains at gcc dot gnu.org wrote: > So I agree, the root problem is that we are creating something that the newer > version of dsymutil doesn't understand - it could be we're making a mistake or > new dsymutil could be still green. I tried to run Clang's llvm-dsymutil form the locally built clang tools. Fails the same way. And the error is coming from this routine: 124 /// Interpret the STAB entries to fill the DebugMap. 125 void MachODebugMapParser::handleStabSymbolTableEntry(uint32_t > What happens if you do a clang link and then do "dsymutil result"? Linking with clang and "dsymutil result" produces similar results - 'failed to insert symbol' messages. But then it complains on lots of object files as it cannot find them. I checked the clang code (and some logs) and clang does NOT call dsymutil for our case. Note that we are compiling through a fairly complex UPC driver, part of Berkeley UPC toolset, and we get this warnings only if our back-end compiler is GCC from our GNU UPC branch (which is in sync with the trunk). Using Clang as back-end compiler does not produce warning as they do not run the tool at the and - linking phase.
