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

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749

--- Comment #36 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-12-05 21:57:06 UTC ---
(In reply to comment #35)
> Surely this design isn't complete as it doesn't cover the changes or the
> requirements for lto.  Without those, I can't review the design to see if it is
> sufficient to actually fix the problem at hand.  The problem is there are
> temporary files removed by subpasses during the subpass.  The above doesn't
> lengthen the lifetime of those temporary files, so can't fix the problem.

Sure it fixes the problem.  dsymutil has to be called from the linker
at which point in time the temporary files are obviously still available
(as compared to the time when the parent driver process invokes it)

> Compare and contrast another potential design:
> 
> Add an environment variable that identifies a file in which additions can be
> made of temporary object files to remove once the link is done.

You probably need a temporary file to store the temporary files due
to limits of environ variable content length.  That file can be similar
to -fresolution handling, which is a temporary file managed by the
driver.

>  If any subpart
> of the compilation process wants to create to create intermediate .o files,
> they can instead write into that named file, the names of the temporary files
> to delete, then the top level driver (one with no environment variable set, can
> delete them, at the very end.  This even works for linker plugin files and
> cover just about every type of tech or architecture for the compilation process
> save distribution, caching and compilation server.  I'd propose we handle those
> later, as necessary.

Sure, that also works.  But it doesn't work for example for makefile
managed temporaries, like

%.o: %.c
   gcc -c $< -o $@

foo: a.o b.o
   gcc -o t $<

dsymutil is not called.   And at install time the temporary objects are gone.
So you need a way to handle the above anyway, and I don't see how the above
is really different from the current problem.  If you'd have dsymutil
invoked from the linker then the problem would not exist.

> The advantages of this over the last one is, it is complete, it would always
> work, regardless of nesting complexities, doesn't require any changes to `ld',
> and works, even when collect2 isn't used.

Well.

Whoever will implement something will probably decide on what he'll implement
(which means, it'll not be me).  If you want to go with managing everything
from the parent driver process I suggest to use sth similar to -fresolution
and not an environment variable.

A linker option to invoke dsymutil sounds useful for me anyway (for the
above problems with makefiles), so fixing the LTO problem with that
sounds then easy.

Managing all temporary files from the outermost driver process will at
least cause the worst case diskspace usage and doesn't allow any
optimization there.