[Bug debug/46749] gcc.dg/debug/pr41893-1.c -gdwarf-2 testsuite failures on darwin

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

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
> 
> mrs@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.