This is the mail archive of the gcc-patches@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]

Re: [patch][plugins] Check the gcc version


On Fri, Apr 24, 2009 at 12:08 AM, Rafael Espindola <espindola@google.com> wrote:
>
>> I really don't think we should ask individual plugins to link against
>> this file. The plugins should require (and depend on) the access to
>> the GCC header files only (which in the future should be packaged and
>> installed with GCC distribution).
>
> We are already installing the headers :-)

Cool! Where do we install the gcc headers? under <prefix>/include? I
couldn't seem to be able to find it in my top of trunk mainline
install directory.

>
>> If a plugin needs to link against a
>> GCC .o file, the plugin support will become too messy (and very weird
>> because, after all, GCC will link dynamically against the plugins) .
>
> Plugins only have to link if they want to check the gcc version. I
> used an object file mostly because it was easy. The only tricky bit is
> that, other then using hidden symbols, the only way for gcc to get the
> plugin version is with dlsym.

I think my point is that a plugin should not need to link in
plugin-version.o in order to check the gcc version. The model that I
was thinking is that GCC will pass its version information to the
plugin (as a parameter to plugin_init function like what you are doing
now), and the plugin will then check whether the given GCC version is
compatible with its requirement. If not, the plugin will emit a
warning and the initialization will fail.

>>
>> Passing the version you dlsym'ed from the plugin back to the plugin
>> seems wrong to me. What we want to do is pass the current GCC version
>> to the plugin, and the plugin can either check it against the version
>> it desires/requires, or simply ignore this parameter and call
>> plugin_default_version_check() with the version it requires. So I
>> think we should remove the call to dlsym for
>> str_plugin_gcc_version_name and change the if-statement ?to
>>
>> ?if ((*plugin_init) (plugin->base_name, &plugin_gcc_version,
>> plugin->argc, plugin->argv))
>
> For that to work I would have to use hidden visibility. With normal
> elf visibility both the plugin and gcc would see the same symbol.
>

Based on the model I mentioned above, there is no symbol visibility
issue between GCC proper and the plugins. Version information is
communicated between GCC and the plugins by function parameter. In
GCC, we first construct a version object (as you are doing now), and
pass it to the plugin during initialization (as shown in the
if-statement above, although we might want to change the object name
from plugin_gcc_version to simply gcc_version). The plugin then checks
the given GCC version and decide whether it's compatible or not.

What do you think?

Le-chun


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