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
