On Fri, Sep 19, 2008 at 15:30, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Ralf Wildenhues wrote:
> Is it really that far fetched to have the plugin not directly access
> anything from the executable's symbol table but instead be passed a
> structure that contains a defined set of interfaces and callbacks? By
> using this strategy you also insulate the plugin from the gcc internals,
Too much so. This goes again back to needing to decide in advance what
will be interesting; that's pretty much a deal-breaker, I think.
No, it sounds to me as if linking at runtime is the way to go for PE.
However, that's not as hard as it sounds.
Essentially, *for each plugin*, you compile a list of all the gcc
symbols that *this plugin* needs. You convert this list into a
structure with a long list of pointers and names, which you hand to a
small routine that resolves all of them (via dlsym(),
GetProcAddress(), or whatever); and the plugin uses the stuff vioa the
pointers in the structure. As the list of symbols needed for that
plugin is both known and relatively stable, the burden from that isn't
too large.
In gcc, you just make all symbols resolvable.
Gcc then loads the plugin, gets a pointer to that structure (via a
well-known symbol name), resolves all symbols therein, and calls some
initialization function so the plugin can register in all relevant
hooks - or one could do even that by putting additional data into that
structure.
And one can also put versioning data therein, so that gcc can check
compatibility before calling the first plugin routine.
Just a quick&dirty mock-up:
struct s_gcc_plugin_info gcc_plugin_info = {
.version = "4.4.0";
.hook = {
{ .name="hook_parse_params"; .proc=&my_parse_params; }
[...]
};
.link = {
{ .name="fold"; .ptr = 0; }
[...]
};
};
and possibly, for convenience,
#define gcc_fold ((prototype_for_fold)(gcc_plugin_info.link[0].ptr))
... gcc_fold(...) ...
All those .name fields are presumably const char *.
And one could presumably write a small utility that, given a list of
names, goes through gcc's headers and constructs that struct and the
convenience defines automatically. If (as is the case here) the
declarations follow a fairly consistent style, this doesn't need a
full C parser.
It seems to me that the overhead, both in runtime and in maintenance,
isn't too bad here.
