This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: using plugin and lto: problem linking c-pragma symbol
On Mon, May 30, 2011 at 10:50 PM, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> On Mon, 30 May 2011 22:15:29 +0200
> Richard Guenther <richard.guenther@gmail.com> wrote:
>
>> On Mon, May 30, 2011 at 7:44 PM, Basile Starynkevitch
>> <basile@starynkevitch.net> wrote:
>> > On Mon, 30 May 2011 17:58:48 +0200
>> > Richard Guenther <richard.guenther@gmail.com> wrote:
>> >
>> >> You can't use language specific functions form a plugin that should be
>> >> usable at link time (from lto1) given that the sources can originate
>> >> from different frontends.
>> >>
>> >> I suppose plugins could be tagged as to which language they are
>> >> tailored to and a more meaningful error could be emitted then.
>> >
>> >
>> > This cannot be a satisfactory answer, because in the precise case shown
>> > by Pierre the plugin is called mostly on a C file. So we definitely
>> > need some way to solve this. I mean that from a user point of view, the
>> > plugin is invoked while compiling a C file, so having it not working
>> > just because of the -flto option is quite strange. From the naive user
>> > point of view, the fact that gcc is running cc1 and lto1 is an
>> > implementation detail. The plugin implementor (which is not the same as
>> > the naive user) should have a way to circumvent that issue.
>>
>> Well, suppose the plugin would be tagged as "uses C frontend functions".
>> The lto1 phase could then either error out when it receives -plugin with
>> such a plugin or simply ignore it.
>
> Yes, the plugin could be informed that lto1 is running, e.g with the
> invoking_program field on struct plugin_gcc_version that I proposed. And
> then, the plugin won't call any C front-end specific function.
>
>>
>> > Pierre suggested:
>> >> Maybe a solution could be to define c_register_pragma and
>> >> others related functions as weak references (however it might not work for
>> >> all platforms or systems).
>> >
>> > Would that be acceptable? Can Pierre try to submit a patch which
>> > declare language specific functions (such as c_register_pragma) with
>> > __attribute__((weak)), probably suitably hidden by some configurable
>> > macro? I have no idea if using such attributes is acceptable within GCC
>> > code.
>>
>> No, it is not. ?At lto1 time the function addresses would resolve to NULL,
>> segfaulting the plugin when it calls the function. ?Now _that_ I call even
>> less user friendly than refusing to load the plugin.
>
> Of course, with weak symbols, I (& Pierre) was implicitly thinking of
> testing them against NULL before using or calling them. This is
> standard practice with weak symbols (google for gcc weak symbol gives
> immediately relevant examples such as
> http://winfred-lu.blogspot.com/2009/11/understand-weak-symbols-by-examples.html
> and others). Using weak symbols without testing them has no sense, and
> I was expecting that everyone knows that -the very purpose of weak
> symbols is that they could be null when not found at dynamic linking
> time... so every program should test them (or it does not need weak
> symbols).
>
>
>> No. ?Think a second before you write.
>
> I did thought more than a second. And I find Richard G.'s tone quite
> agressive (sadly, as often with newbies or me)...
>
> At least on the MELT branch & the MELT plugin, Pierre will probably add
> some code to glue MELT with C pragmas -very probably using weak symbols
> in the MELT plugin-, and of course this will be done so that it will
> work (at least not segfaulting but ignoring pragma handlers in lto1)
> appropriately.
>
> By declaring C front-end specific functions -such as those related to C
> pragmas- available to plugins as weak (and by documenting that) and by
> transmitting to the plugin the information that it was invoked from cc1
> or from lto1, we could have a solution to that issue.
>
> To be more specific, if ?c_register_pragma & pragma_lex are declared
> weak, and if the gcc/testsuite/g++.dg/plugin/pragma_plugin.c is changed
> to test them, e.g. having there
>
> static void
> register_my_pragma (void *event_data, void *data)
> {
>
> ?/* added test inside pragma_plugin.c */
> ?if (!c_register_pragma || !pragma_lex)
> ? ?{
> ? ? ? ?warning (0,
> ? ? ? ? ? ? ? ? "cannot register plugin pragmas without C frontend");
> ? ? ? ?return;
> ? ?}
>
> ?warning (0, G_("Callback to register pragmas"));
> ?c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
> }
>
> then I would imagine that Pierre example would not make any error, just
> the "cannot register plugin pragmas" warning I just added. I admit that
> I did not test that.
>
> The question becomes, should Pierre start to work on such a patch (for
> the trunk) or not? If it is sure that such patch will be rejected,
> Pierre should not waste his time.
Such patch would be rejected. The idea of declaring the function weak and
doing this kind of test is a sign of our bad (or non-existing) plugin API.
Instead we need to devise a better way to handle this.
A very simple compromise would be to continue to say "this case
is not supported" but instead for such plugins require that they
access language specific functions only through langhooks
(which you already can test agains NULL, or through which you can
query the source language). That's also the only way this will work
on platforms that do not support weak symbols. We could then,
reasoning with the plugin use, add additional langhooks encapsulating
functions such as c_register_pragma (possibly under a
lang_hooks.plugin substructure).
The point I want to make is that we need to move away from the
current "plugins can access each and every non-local symbol from GCC".
Instead we need to expose a defined set of functions and structures,
and we can easily provide them through indirect dispatch (which opens
the possibility for a stable API even when the internal API changes - to
some extent at least).
Btw, instead of weak symbols you can also lookup the symbol
via dlsym () and store the result in a function pointer variable.
Richard.