This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

mudflap versus cgraph


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 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'm
not a big fan of this though.  Another possibility is to create a
special static-data-table section for mudflap's benefit: given

        .data
        .type x, @object
        .size x,4
x:
        .word 23

we might emit in addition

        .section .rodata.mf.statics, "a"
        .long x
        .long 4

That can be handled entirely within varasm.c; it completely eliminates
the need for the static constructor.  A registration function in
crtbegin runs over the table and calls __mf_register.  This might not
play nice with PIC mode, though, and might require modifications to
linker scripts.  (I'm pretty sure mudflap already doesn't work on
targets without named sections.)

I'm open to suggestions.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]