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

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

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

--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-03 11:29:59 UTC ---
(In reply to comment #26)
> 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
> > > 
> > > 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.

r167292 has fixed the problem with the suffix recognition.
(I suspect that the bug you fixed predates the inclusion of the spec, thus the
spec has never worked 100% on trunk)

> > 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).

my understanding is that dsymutil only takes the linked executable as its
command line argument - and looks up the objects from the tables therein.

The debug is then extracted from those objects, linked and placed into the
.dSYM and then the objects are unlinked.

Therefore, somehow I assume that the linked exec is referring to an object
which has gone away.
(if it's actually the wrong object,  then that's a potentially more serious
issue).

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

AFAIK dsymutil requires only (a) the linked exec. and (b) that the objects used
to link it are still available.  
It's not obvious to me how we (within the FSF community) can simplify that or
make it more robust.

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

sudo dtruss -f  -t syscall ./xgcc...  > log

might be helpful, cheers,  Iain