http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:47:49 UTC --- On Fri, 3 Dec 2010, mrs at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 > > m...@gcc.gnu.org <mrs at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mrs at gcc dot gnu.org > > --- Comment #24 from mrs at gcc dot gnu.org <mrs at gcc dot gnu.org> > 2010-12-03 00:26:37 UTC --- > The lto people need to engineer a design in which the debug information is > left > around in .o files, and those files are read at the very last step in a link, > to collect the debug information from them and persist that information into > the filesystem. They are removing .o files before the end of the final link. > To the extent those files have debug information in them, this can't work. > > I could not find the last invocation of gcc that fails. If someone could > point > that out, I might be able to suggest a work around that just disappears debug > information until such time as the first bug is fixed. Essentially, you can > remove -g* from that line and disappear the collection of the debug > information. Another solution would be to not have any .c, .cc, .C, .cpp, > .cp, > .c++, .cxx, .CPP, .m, .mm, .f, or .s files on that line. I didn't manage to prove the following theory but it's the only that makes sense. What I think happens is the following: User says gcc -o t t.c -flto We now do the usual compile ./cc1 -c -o /tmp/xyz.o t.c -flto and now execute the link-spec which matches the symtool thing (but on the wrong object file!). So, we now link. Which will do collect2 ... which executes lto-wrapper which executes gcc -c -x lto -o /tmp/abc.o /tmp/xyz.o -flto and then collect2 continues and links collect2-ld ... -o t /tmp/abc.o only _now_ dsymutil is invoked (from the first link-spec!) and on /tmp/xyz.o, which isn't the correct object file either. But somehow that intermediate file has disappeared at this point (I have yet to see who is responsible for cleaning up that one and when it does so). Thus, the setup is broken anyhow, even if we manage to retain the object file for long enough. The darwin people have to design a more robust way to run dsymutil. Richard.
