Basile STARYNKEVITCH wrote: > But what about the trunk, which uses tuples? I know nothing about the tuples and the trunk and whether tuples might affect the way plugins work. Maybe others can comment...
To be honest i was more worried about how plugins will work with the garbage collector and pre-compiled headers... I assume there is no problem with this though since there are already a number of plugin frameworks that exist that people report are working. > Are the below hooks the name of dlsym-ed symbols inside the plugins, > or the name of some (new or existing) functions? >> - c_common_init(), c_common_finish(), finalize(), >> gimplify_function_tree() They are the names of functions in GCC 4.0.4 that i currently modify to call my code (I am not using a plugin framework at the moment but distributing a patched GCC so i have statically linked my code into GCC and called it from these places).It was earlier recognised that we will need hooks into the pass management, i was just adding the areas outside the pass manager that i have used. If we have an idea of the "hook locations" everyone uses it may help get an idea of what may be required of the plugin framework in terms of locations in GCC where plugins can hook into. Those were the locations i used. > How do we interact with the pass manager? Some plugins definitely want > to add new passes... How does that happen concretely? I imagine others who have attempted this will comment. > Agreed, but perhaps this autoload feature is not the first priority. > Making plugin working inside the trunk seems more important to me than > the autoload thing. At last, autoload plugins might slow down quick > compilation of very small files (but do we care?). Well Ian just provided a different mechanism for projects like mine to achieve the result i was after without automatically loaded plugins. So i will assume that this feature is canned for the moment unless there are other needs for it. > A related issue (which does not seems a priority to me) is do we want > to make easy the process of moving a plugin inside the core GCC code, > precisely to avoid that (ie having significant optimisations as plugins). To start with i can imagine that no core features will be moved to plugins, maybe in later versions that might happen but i cant imagine doing so would be overly difficult. > And there is one significant point we did not discuss yet. Compiling a > plugin should if possible be doable outside of GCC source code; this > means at least that the gcc/Makefile.in should have stuff to copy all > the relevant *.h files usable by plugins outside. Yes. A location where we can place the headers/libs was mentioned by Joseph ($libsubdir) along with suggesting we create an autoconf macro that external projects can use to locate and use those headers and the library. > Maybe this is not the business of GCC, and only an issue for GCC > packagers. In general, we should have a convention for the file path of > installed plugins : do we want them only in system places like > /usr/lib or also a per-user directory like > $HOME/.gcc-plugin-dir/4.5.0/ ; we also need a convention for the > location of all the related *.h files needed to compile a plugin > outside GCC source tree. (or is this a packaging issue only, ie have > not only a gcc-4.5 package in debian, but also gcc-4.5-plugins-dev > package? - but that should mean additional install* targers in our > Makefile.in). I would assume the following (Say we make a libgccimpl that contains the code for GCC except the stub main() that calls gcc_main() from the library): Install libgccimpl to: $(libsubdir)/libgccimpl.so.4.3.2 Install the headers to: $(includesubdir)/*.h Install plugins to: $(libsubdir)/plugins/*.so GCC would install these things every time it is installed, and it is the job of packagers for the various distributions to split it into different "subsets" if they so desire. So searching for plugins (using libltdl) would look first in: $(libsubdir)/plugins, followed by $LTDL_LIBRARY_PATH, and $LD_LIBRARY_PATH. The issue with searching anywhere other than $(libsubdir)/plugins, is knowing if the plugin that is found is compatible with the given version of GCC. For example: Say a system has two versions of GCC installed: 4.3.2 and 4.4.3. A user then wants to install a plugin but does not have the privileges to do so in $(libsubdir)/plugins/*.so for the specific versions of the GCC compiler. So they build the plugin say for version 4.3.2 and install it in their home directory somewhere. If they then invoke GCC 4.4.3 with -fplugin=edoc, there is a possibility that GCC 4.4.3 will find the plugin the user build for 4.3.2 and try to use it (If the user is not careful with their environment i.e. Setting LTDL_LIBRARY_PATH). This will cause undefined behaviour. We have a few options: 1) Dont allow additional search paths for plugins 2) Ignore the problem and put it down to the user needs to understand what they are doing 3) Somehow embed something in all plugins that can safely be queried, which indicates the version/build of GCC the plugin belongs to and only load plugins that match. There may be some other options? The above example, is more likely to happen when versions of GCC are upgraded but the plugins are not. > Yes. The minor point is should we avoid loading plugins when they are > not used? My view is that this is not a priority. But I am probably > not caring enough about the time of small compilations (i.e. the time > of gcc -O0 helloworld.c) Plugins will only be loaded on request with the -fplugin=<name> option. So there is no overhead unless a plugin is requested (I.e. Autoload of plugins is not required for now). > We really should not care about plugins on plateforms without dlopen. > What is more important is that GCC should be configurable to have > plugins disabled and still (at least) be able to compile itself (or > perhaps a reduced version of itself). Agreed. Using libltdl we can achieve this, even if plugins are necessary to build GCC itself, as it just links them in statically and "pretends" they are dynamically loaded. > I would prefer that (ie using -rdynamic). Perhaps a convention (i.e. > adding a EXPORT_PLUGIN macro to mark exported symbols) should be defined. The issue is, if we want to support windows, we need to mark ALL symbols that may be used with an export macro. Otherwise, we can just use the -rdynamic, not use hidden visibility building the GCC application. Basically it is a matter of time/effort. To support Windows we would need: * EXPORT macro marking of all code used externally * All code compiled into a separate library with a stub main() application Otherwise, for most ELF platforms (with default visibility) we don't have to mark anything exported and dont have to move the code into a library like libgccimpl.so. Do we say for the first version we use -rdynamic and don't support windows (will need build machinery to disable all this on windows if we do) or do we add the export macros and library and support the windows platform from the beginning (Are there any other platforms with quirks not covered here)? I may not be able to work on the wiki page or reply to any messages for about 3 days as it seems my phone line at home has gone down and thus so has the internet. I will check back sometime after that and see how best to summarise peoples responses on the wiki. Thanks, Brendon.
