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: > >> On Mon, May 30, 2011 at 5:53 PM, Pierre Vittet <pier...@pvittet.com> wrote: >> > Hello, >> > >> > I try to use the plugin pragma-plugin.c which is given in the testsuite >> > (gcc/testsuite/g++.dg/plugin/pragma_plugin.c), I have compiled it as a >> > shared library. >> > >> > If I try it on a simple c file it works, however, if I use -flto it causes >> > an error: >> > >> > gcc -fplugin=./pragma_plugin.so -flto test.c >> > >> > lto1: error: cannot load plugin ../pragma_plugin.so >> > ../pragma_plugin.so: undefined symbol: c_register_pragma > [...] >> > What would be the better way to patch this? >> >> 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. > 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. > Another possible solution would be to have the plugin code be informed > of the context in which it is used. Perhaps the less intrusive way of > implementing that would be to add more fields into struct > plugin_gcc_version to convey that information. For instance, we could > add a field into struct plugin_gcc_version of gcc-plugin.h > /* after configuration_arguments field */ > const char*invoking_program; > > and have the plugin machinery pass the argv[0] into that > invoking_program (which would be "cc1" or "lto1"). Then the plugin > itself could use various tricks (notably weak symbols) to avoid calling > c_register_pragma ... Huh. Either the plugin is a frontend plugin, then it has no purpose running from lto1. Or it is a middle-end plugin, then it has no purpose calling a C frontend function. So, I can't really see an issue apart from gcc -flto passing down -plugin options even when the plugin is frontend specific (for which there is no way currently the driver could know this). > Diego and other people interested in plugins, what do you think of such > a proposal? > > I still strongly believe that we cannot just say: plugins should not do > that. A plugin -the same plugin.so- should be possible that work with > and without -flto. No. Think a second before you write. Richard.
