R: R: R: R: Plugin development under windows

Davide Piombo Davide.Piombo@phase.eu
Thu Mar 30 07:27:00 GMT 2017


Hi Pedro,
thanks a lot for your message, it clarified me a lot of things.

Actually I have no time to try to change GCC plugin code to make it working in Windows, in order to solve my problem I will move to another solution, maybe in the future...

Cheers
Davide



> -----Messaggio originale-----
> Da: Pedro Alves [mailto:pedro@palves.net]
> Inviato: mercoledì 29 marzo 2017 12:38
> A: Davide Piombo; 'Trevor Saunders'
> Cc: 'Joseph Myers'; David Malcolm; 'gcc@gcc.gnu.org'
> Oggetto: Re: R: R: R: Plugin development under windows
> 
> On 03/29/2017 08:30 AM, Davide Piombo wrote:
> > Hi Trevor, thanks for your hint.
> >
> > Yesterday I made some other tests. I tried to use CygWin instead of
> > MinGW and the POSIX missing references are now solved. Now the error
> > have moved from the compiler to the linker and the build stops
> because
> > of undefined references. The missing symbols are included in GCC
> > executable and are declared as external symbols in GCC plugin header
> > files.
> 
> Declared as external is not sufficient.  They also need to be declared
> as exported in PE terms.
> 
> Usually, you do that by tagging exported symbols with
> __declspec(dllexport) at the time the exe is built, and tagging them as
> __declspec(dllimport) when the plugin is built.
> 
> I.e., you'd apply the guidelines described at:
> 
>   https://gcc.gnu.org/wiki/Visibility
> 
> to GCC itself.  E.g., add a macro like the DLL_PUBLIC described there,
> something around:
> 
> #if defined _WIN32 || defined __CYGWIN__ # ifdef BUILDING_GCC
> #   define GCC_PUBLIC __declspec(dllexport)
> # else
> #   define GCC_PUBLIC __declspec(dllimport)
> # endif
> #else
> # define GCC_PUBLIC
> #endif
> 
> And add GCC_PUBLIC to symbols that should be exported to plugins.
> 
> AFAIK, in plugin architectures on Windows, it's more common to split
> the bulk of an exe to a dll that is then linked by both a "shim" exe
> and the plugins, but exporting symbols from EXEs should work fine too.
> See e.g.,:
> 
>   http://stackoverflow.com/questions/3752634/dll-get-symbols-from-its-
> parent-loader/3756083#3756083
>   http://stackoverflow.com/questions/15454968/dll-plugin-that-uses-
> functions-defined-in-the-main-executable
> 
> The key search terms are "plugins on windows export exe symbols".
> 
> My Windows knowledge has been steadily fading over the years, and I'm
> not sure whether GCC export all symbols automatically using "-
> fvisibility"
> on Windows (as workaround) of whether you really need to go the
> __declspec or dllexport routes.
> 
> Also, see:
> 
>  https://gcc.gnu.org/onlinedocs/gcc/Microsoft-Windows-Function-
> Attributes.html
> 
> maybe you can also workaround it by using LD's --export-all.
> 
> This should give you some pointers to experiment.
> 
> > Anyway, before to change the compiler or library version I tried to
> > dump symbols from libgcc.a in order to understand if missing symbols
> > are really in this library and they are not there.
> 
> libgcc.a is not GCC itself.  See:
> 
>   https://gcc.gnu.org/onlinedocs/gccint/Libgcc.html
> 
> Thanks,
> Pedro Alves



More information about the Gcc mailing list