https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Nenad Vukicevic from comment #6) > On 11/24/15 9:27 AM, dominiq at lps dot ens.fr wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68358 I suspect we have two issues here: > Maybe line 820 should pass 'false' as this is the case similar to LTO > not being enabled? That seems reasonable a first blush, we should _not_ call dsymutil for gcc foo.o bar.o -g -o t And we plainly do.. The purpose of dsymutil on the link line is to preserve debug info from temporary files. so for: gcc foo.c -g -o t /tmp/blah-foo.o is created and used to link "t" ... but t doesn't contain the debug info (only references to the .o files) and the (/tmp) .o files will be deleted at the end of the link. Step in dsymutil which links the debug info into a t.dSYM .. and we're all happy. Normally for gcc foo.o bar.o -g -o t there is no need for dsymutil because foo.o and bar.o (which contain the debug data) will be available after the link. In the case of an lto link: gcc foo.o bar.o -flto -g -o t now we have a situation where, if foo.o, bar.o (or both) contain lto data this will be linked - and then the compiler will run generating a /tmp/lto-blah.o based on the lto'd input. This temp file will be deleted one the final link is done - and we'd be back to losing debug info. So we have it run dsymutil if we're doing lto, and a temporary file is created. We seem to have the logic wrong / insufficient so that it is getting run when there is no (apparent) need. ---- I's not immediately obvious that clang is DTRT if it doesn't run dsymutil for the same scenario (but let's leave that to one side for now). ---- > I think the problem is in the symbols we generate, or the tool itself, > and this issue shows up only if you have LTO enabled. I can provide the > object file that has problems and this might be enough if someone builds > LLVM on Apple and tries llvm-dsymutil tool on it. This should be the > same tool as Apple's dsymutil, if we can duplicate the problem then we > can debug it. 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've got a TOT clang build and will investigate a bit. What happens if you do a clang link and then do "dsymutil result"?
