http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-03 10:51:06 UTC --- On Fri, 3 Dec 2010, rguenther at suse dot de wrote: > 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. Btw, I would have tried to dig deeper but darwin lacks basic tools such as strace which I am familiar with, so I was lost (fortunately for you I now do have access to a darwin x86 machine). So if you can hint me at what's the equivalent of strace -f -e unlink,execve -o log ./xgcc ... on darwin that would help. Richard.
