Re: mudflap versus cgraph

[Jan Hubicka <jh at suse dot cz>]

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

And also I can do it before 30th if this gets urgent (like fixing 3.4.1,
just I won't be able to respond very quickly).
I wonder why it broke for you - in the case you are sure that everything
mudflap function touch is output to the assembly file, the hack of
bypassing cgraph code should just work for a moment (I definitly don't
like it, but I don't like the idea of adding function into cgraph late
too, but we probably need this kind of functionality. There are two
other places we need similar kind of tricks; the objc interface
functions I don't 100% understand to yet and initializers for static
datastructures in C++.  The objc case is currently dealt by similar way
as mudflap, while in C++ we simply emit all constructors that appears to
be neccesary forcing the datastructures to stay even tought they are
unused that is definitly bad.  Richard had work in progress patch for
the C++ problem - basically right thing here seems to be to teach cgraph
about the initializers and make it to output the constructors as needed,
but I am unsure about current status)
> 
> 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
> >