On Mon, 30 May 2011 22:15:29 +0200 Richard Guenther <richard.guent...@gmail.com> wrote:
> On Mon, May 30, 2011 at 7:44 PM, Basile Starynkevitch > <bas...@starynkevitch.net> wrote: > > On Mon, 30 May 2011 17:58:48 +0200 > > Richard Guenther <richard.guent...@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. And inside the MELT branch & plugin we could just forcibly add a weak declaration of c_register_pragma & pragma_lex (just in file melt-runtime.c), so I expect that would work (i.e. won't crash or error, but won't do anything useful) even with gcc-4.6 -flto -fplugin=melt Of course, my solution depends on working weak symbols. I imagine these are common on most ELF systems with dlopen (but such systems are the usual ones when using GCC plugins) Regards -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
