Paul Brook wrote: > If you really want to solve this then you could always stop using PE/COFF. > The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates > how this can be done. Basically the toolchain generates ELF objects, > executables and DSOs, then you feed them through a postlinker to generate > target (PE/COFF) images.
Using ELF as an intermediary format doesn't really change the situation facing the design of plugins in any meaningful way though. If the end result is still PE/COFF executables and DLLs then the same problems and restrictions still exist that would make the current proposed design unworkable on these Windows targets. If you recall the issue is that plugins want unfettered access to the full symbol table of the executable. Doing this with PE/COFF is possible, but it binds the plugin DLL to the specific name of the executable that it was linked against, such that the same plugin wouldn't be loadable from cc1.exe, cc1plus.exe, f951.exe, etc. To get around this you'd have to either link a separate copy of the plugin for each executable, or access the symbols in the executable indirectly through GetProcAddress and function pointers. Brian
