mudflap versus cgraph

[Mark Mitchell]

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.

>I have not been able to think of a resolution to this problem.  It
>might be acceptable to wind the enqueue/emit logic into cgraph itself,
>provided that we could figure out how to construct a function in a
>completely language-independent manner (which we need anyway).
>
I think you just need to call a target hook to do that, for now -- which 
is what mudflap seems to be doing anyhow.

Is this for your IMA fixes?  It might be that mudflap has to be broken 
for a while, while IMA gets fixed...

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com