http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #18 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 22:06:23 UTC --- (In reply to comment #16) > On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749 > > > > --- Comment #15 from Iain Sandoe <iains at gcc dot gnu.org> 2010-12-01 > > 21:34:19 UTC --- > > splitting the command into compile and link steps will intentionally remove > > the > > dsymutil step - thus making the problem 'go away' ... > > > > dsymutil should _only_ be called if there is a source file on the c/l > > (which would have its object deleted and thus be unavailable for debug). > > Huh, ok. But the spec seems to call it unconditionally in the > link-command-spec when -g is visible. At least I can't see how > a "source file" is matched (and we now definitely do find object > files as source for the link step). it is matched (with the noted hacky & buggy behavior) by the list of suffixes. > And the issue is probably that we match on the intermediate link > command but execute only after that is finished. OK > Well, that dsymutil hack looks like a hack. yeah - it's on my TODO (pr43751). FWIW, some time ago, I did enquire about the difficulty of adding an intentional additional post-link phase, with the feedback that it was prob. not easy.
