> On 06/30/2010 03:46 PM, Dave Korn wrote: > > 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.) > > Long term we could arrange for libbackend.a to become libbackend.dll and > have that library be used for plugins. The existing practice of linking > back into the main executable is more or less an efficiency hack that > happens to work with ELF.
It also makes WHOPR with -fwhole-program possible on GCC. If we will want to have dynamically linkable backend library, we would need to clean up our interfaces quite a lot so frontend does not link into backend other way than by langhooks. (or make other crosslinking explicit via externally_visible) Not that would be a bad thing. I made absolutely no measurements yet if linking frotned into backend improves performance in any sensible way. Honza > > > r~
