This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Defining a common plugin machinery
On Fri, 19 Sep 2008, Brendon Costa wrote:
> 1) Dont allow additional search paths for plugins
I think we do want to allow the user to specify such a path on the
compiler command line, in addition to searching the standard libsubdir or
libexecsubdir location.
> 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.
I think the required GCC version should be exported by the plugin - in
addition to the plugin's own version and bug-reporting URL which should go
in the --version and --help output if those options are used together with
plugin-loading options. It should also export the configured target
triplet since plugins built for different targets on the same host can't
be expected to be compatible (they may use target macros internally).
We should make it clear that e.g. 4.5.0 and 4.5.1 are not necessarily
compatible for plugins; that's an inevitable consequence of exporting all
the GCC-internal interfaces. Thus the full version number is what should
be checked, rather than trying to keep interfaces stable within e.g. the
4.5 series. But we do want plugins to be usable from both cc1 and
cc1plus, etc., unless they use front-end-internal interfaces (which some
may wish to do, at the expense of only working with one language).
> 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)?
There are many supported non-ELF hosts with their own peculiarities - not
just Windows - Darwin (Mach-O), HP-UX on 32-bit PA (SOM), older BSD
versions (a.out), Tru64, VMS, DJGPP, AIX. I think it's very likely the
support will initially be optional and only supported on a subset of hosts
- but with nothing in the core compiler moved to plugins this should not
cause any problems with the invariant of generating the same code for a
target independent of host.
--
Joseph S. Myers
joseph@codesourcery.com