mudflap versus cgraph

[Jan Hubicka]

> Mark Mitchell <mark@codesourcery.com> writes:
> 
> > Zack Weinberg wrote:
> >
> >>mudflap has a pass-ordering conflict which I cannot figure out how
> >>to resolve.  mudflap_finish() generates and emits a function
> >>(calling tree_rest_of_compilation directly) after cgraph_optimize()
> >>has been called, which is wrong.  But it has to do that, because the
> >>set of items to be registered with the mudflap runtime at static
> >>construction time is only determined at final assembly output time
> >>-- the callers of mudflap_enqueue_decl/mudflap_enqueue_constant are
> >>in varasm.c.
> >>
> >
> > I think that's the problem.  In the cgraph world, the arbiter of
> > what things are needed is cgraph itself.  There should be a hook
> > that cgraph calls to add additional functions -- after it has
> > already decided on everything else.
> 
> Right (although there is a concern about later optimization passes
> eliminating the need for some variable or (more likely) constant).
> But that's way more invasive than I want right now.

I can implement such a function, but it will definitly have a
restrictions in a way that it should not touch anything that was not
marked as possible entry point.  Objc is using similar hacks as mudflap
do BTW (bypassing cgraph and adding functions directly)
I will be partly offline till 30th, but I can definitly do it after
that.

Honza
> 
> > Is this for your IMA fixes?  It might be that mudflap has to be
> > broken for a while, while IMA gets fixed...
> 
> Yeah, it's for IMA.  If it's mudflap's turn to be broken for awhile I
> don't have a problem with that, but I didn't want to spring it on
> people with no notice.
> 
> zw
>