Plug-ins on Windows

[Joern Rennecke]

[gcc plugins rely on ELF features and therefore don't work on MS windows]

Quoting David Brown <david@westcontrol.com>:

> In reality, if embedded developers are unhappy (for whatever reason)
> with running gcc on Windows, they will move to proprietary compilers
> under windows - not gcc on Linux.
>
> Of course, this is not a problem at the moment - gcc plugins are
> currently only for particular special purposes and specially interested
> developers and users, and so requiring Linux is not a big issue.  But
> as gcc plugins become more mainstream, it will become a limitation.
> Should the famously cross-platform, cross-host, cross-target gcc now be
> limited to specific hosts?

The main utility of plugins is that they make developing, testing and
deploying modifications to gcc easier.  I don't think that MS windows users
will miss too much if they can't dynamically load the plugins, as long
as their sysadmin can provide them with a linked-in version - the sysadmin
might actually be happier about the greater control, as plugins are
potential virus/trojan vectors.
It makes sense to write a plugin in such a way that it can alternatively
be used as a GCC patch - in the sense that you add the code alongside
the main gcc code and it gets linked in.
Maybe we should create an interface for linked-in plugin code, i.e.
arrays of plugin names and their plugin_init function so that they can
be activated with a matching -fplugin=built-in:NAME (or propose a different
syntax if you think of a better one) and get passed any plugin options
like a dynamically loaded one would.

The plugin_init function name would of course have to be mangled or put
into a namespace to avoid clashes with other plugins.