Plug-ins on Windows

[David Brown]

On 01/07/2010 00:46, Dave Korn wrote:
> On 30/06/2010 21:38, Kyle Girard wrote:
>> Hello,
>>
>> I am playing around with a plug-in for gcc but recently ran into the
>> road block that plug-ins aren't supported on Windows.  Are there any
>> plans to add support for the windows platform in the future?  If not,
>> what are the issues with supporting Windows and how much effort would it
>> be to add support?  I'm assuming that since it's not done already there
>> has to be some difficulty somewhere...
>
>    The main problem is that plugins rely on the property of the ELF format that
> you can leave undefined references in a shared library and have them filled in
> by symbols exported from the main exe at runtime; they use this to call the
> various functions exported from GCC, like register_callback, and to access
> global variables and so on.
>

Isn't that an unusual way to handle plugins and callbacks?  It also 
sounds to me like it would make a lot of co-dependencies between the 
main gcc parts and the plugins, and make it hard to modularise.  I would 
have thought a better way for gcc to export functions (or data) to the 
plugin is by calling some sort of "register" function in the plugin, and 
passing references over.  In other words, gcc should call a 
"register_callback" function in the plugin, not vice versa.

I haven't implemented a plugin system on either Windows or Linux, nor 
looked much at gcc plugins, so I could be way off the mark here.

But it strikes me that a system where the main programs and the plugins 
are directly linking to each other is going to make it hard to separate 
the development of the two sides, and hard to distribute compiled 
plugins that will work with separately compiled main binaries.  And 
surely it is this sort of separation and modularisation that is the 
whole purpose of the plugins?

For the "average" gcc user running Linux and with a single version of 
gcc producing native code, it doesn't matter much - they've either 
compiled their plugins at the same time as their gcc binary, or (more 
likely) their Linux distribution maintainers compiled them at the same time.

But gcc is far more flexible than that.  I use gcc for perhaps six 
different targets on a regular basis, with a variety of versions of gcc 
for some of the these targets, with different hosts (Windows or Linux), 
and with different target OSes (mostly bare metal elf, sometimes Linux, 
and some old bare metal coff).  To my mind, a plugin that works for 
gcc-mips-linux-4.5 should work without recompilation for 
gcc-arm-elf-4.6, assuming the same host.  And it should be possible to 
build the plugin binary for Linux, Windows (native/mingw, not just 
cygwin) and other major gcc hosts (Mac, BSDs, etc.).  Like it or not, a 
great deal of cross-compilation embedded development is done using gcc 
on windows, and it's a shame if something as potentially powerful as gcc 
plugins is not available to those users.


>    Although we could build plugins as Windows DLLs and have GCC load them at
> runtime, if those DLLs needed to refer to anything in the main GCC executable,
> it would have to be specifically linked to import it - and imports on Windows
> have to explicitly specify the name of the DLL (or executable) they are
> imported from.  That means that the plugin would need to explicitly refer to
> cc1.exe or cc1plus.exe, etc; we'd need to build separate versions of the
> plugin for each of the different GCC language compilers.
>
>    (Long term, we might be able to extend the toolchain and libltdl to
> co-operate to do this kind of deferred runtime linking for us, but that's not
> imminent.)
>
>> Would it be a lot faster/easier to create a custom gcc that
>> has my plug-in compiled in directly for the windows platform?
>
>    Yes, much!  At least for the foreseeable future.  Sorry.
>
>      cheers,
>        DaveK
>