This is the mail archive of the
mailing list for the GCC project.
mudflap versus cgraph
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc at gcc dot gnu dot org, Frank Eigler <fche at redhat dot com>, Jan Hubicka<jh at suse dot cz>
- Date: Mon, 21 Jun 2004 21:14:04 -0700
- Subject: 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
.type x, @object
we might emit in addition
.section .rodata.mf.statics, "a"
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.