Re: [plugins] [patch] Initial implementation of GCC plugin support

[Taras Glek <tglek at mozilla dot com>]

Joseph S. Myers wrote:
> On Tue, 24 Feb 2009, Taras Glek wrote:
>
>   
> > Zbigniew Chamski wrote:
> >     
> > > > gcc -fplugin=whatever --version needs to output plugin version strings
> > > > (probably calling cc1 with appropriate options to make it load plugins and
> > > > output their versions).  Likewise --help, with plugin bug reporting
> > > > addresses.
> > > >     
> > > >         
> > > Looks like at least two mandatory strings to be provided by all
> > > plugins: say, 'plugin_version_string' and 'plugin_help_string', maybe
> > > also 'plugin_contactinfo_string'.  In order to ensure uniform behavior
> > > (and to enforce the presence of non-NULL help strings) the machinery
> > > for printing the help message should be implemented in the compiler,
> > > not in the plugin.
> > >   
> > >       
> > Could we avoid strings as much as possible? Or at least have an api for
> > parsing the gcc version? Currently it's really hard to figure out the version
> > of gcc that we are running in. Would be nice to have something like
> > struct gcc_version {
> > int major; int minor; int micro; char *suffix;
> > }
> > that the plugin could query and compare.
> >     
>
> This subthread is about the plugin's version and bug reporting 
> information, not GCC's.
>   
Indeed, but solving one API issue might help improve the other.
> All GCC will do with the plugin's information is report it to the user, 
> e.g. from --version:
>
> gcc (GCC) 4.5.0 20090321 (experimental) [trunk revision 150000]
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> Plugins in use: foo bar.
>
> foo 1.23
> Copyright (C) 2009 Foo Author
>
> bar 2.34
> Copyright (C) 2009 Bar Author
>
> and similarly from --help:
>
> ...
> For bug reporting instructions, please see:
> <http://gcc.gnu.org/bugs.html>.  Do not report bugs involving plugins
> here unless you can show the bug is in code outside the plugins; report
> them to the plugin maintainers.
>
> For bug reporting instructions for plugin foo, please see:
> <http://foo.plugin.example/bugs.html>.
>
> For bug reporting instructions for plugin bar, please see:
> <http://bar.plugin.example/bugs.html>.
>
> and something similar in the ICE message that also gives bug reporting 
> information.
>
> GCC does not need to assign any meaning to a plugin's version number, just 
> report it to the user.  As for the other way round, I'd agree that it's 
> useful to make the information about the GCC version available to the 
> plugin in a way that it can use for conditional compilation - possibly the 
> installation of a plugin-enabled GCC can, along with other GCC-internal 
> headers for use of plugins, install in a suitable 
> host-and-target-and-version-dependent directory a generated header with 
> the components of the GCC version number in a convenient form.  Strict 
> consistency checks in GCC, and GCC-provided plugin build infrastructure 
> that automatically embeds the full GCC version string into the plugin, 
> mean that the version number pieces can always be made available when the 
> plugin is compiled.
>   
There are other uses for the gcc version information so it would be 
handy to export a more verbose version at runtime that's easier to match 
on. For example in Treehydra we reflect GIMPLE into JavaScript, then the 
JavaScript code can make decisions on what GIMPLE contains based on the 
version provided by GCC.
This way we support writing analysis scripts that are more or less 
version-independent even if the actual gimple changes. For example, our 
analyses are the same on both mac (with apple gcc4.2, yuck) and GCC 4.3 
on Linux. When the script is instantiated, the gimple js library wrapper 
uses different functions based on which gcc version it's loaded into.
Once GCC 4.4 is out we'll probably adapt our code to support that GIMPLE 
revision too.

Taras