http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46749
--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> 2010-12-02 08:52:14 UTC --- On Wed, 1 Dec 2010, iains at gcc dot gnu.org wrote: > 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. I thought about adding it to the collect-ld script instead. Why do we want it only if there is a .c source available? That doesn't make sense to me ... but i have no idea what dsymutil is supoosed to do, so ...
