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. 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. 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 ... 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. 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} ***
