Plugin development under windows

Plugin development under windows

[Davide Piombo]

Hello,
I'm interested in developing a plugin to parse some custom annotation in C+=
+ code.
I already developed a preliminary version of this plugin under linux and it=  works fine.
The final platform target of the plugin is (unfortunately ;-)) Windows and = I tried to rebuild the plugin using MinGW compiler (both with the Linux ver= sion as well by using MSYS2 and win-builds MinGW compilers for windows) but=  the lack of POSIX includes breaks the build.

I looked around the documentation but I didn't find any reference regarding=  the use of GCC plugins under windows.
I only found some old posts on some forums saying  that it is possible to d= o that and that exist some old gcc versions (custom windows rebuild of GCC =
4.6.1 to use dragonegg as plugin) that can run plugins.

Substantially I'm writing just to ask:
Can GCC plugins run on a windows build of GCC compiler (MinGW) ?
If it is possible to do that, which is the correct way to build the plugin?

Thanks in advance
Davide

Re: Plugin development under windows

[David Malcolm]

On Mon, 2017-03-27 at 11:18 +0000, Davide Piombo wrote:
> Hello,
> I'm interested in developing a plugin to parse some custom annotation
> in C+=
> + code.
> I already developed a preliminary version of this plugin under linux
> and it=  works fine.

Excellent.

> The final platform target of the plugin is (unfortunately ;-))
> Windows and = I tried to rebuild the plugin using MinGW compiler
> (both with
> the Linux ver= sion as well by using MSYS2 and win-builds MinGW
> compilers for windows) but=  the lack of POSIX includes breaks the
> build.

(FWIW I've worked a lot with gcc plugins, but not on Windows).

You say "the lack of POSIX includes breaks the build".
Can you give more specifics on what goes wrong?  Maybe someone here can
figure out a good workaround/bugfix.

Sorry if I'm being obtuse here, but you say "the final platform target
of the plugin is...Windows" - does that mean that
 - the compiler (and thus the plugin within it) are going to run on
Windows, and generate code for some (other?) system or that 
  - the compiler+plugin are going to run on some (other?) system, and
generate code intended to run on Windows?

(AIUI the former case would mean that Windows is the *host*, the latter
that it's the *target*).

I believe that compiler plugins needs to be built using the same build,
host and target configuration triplets as the compiler they're going to
be embedded in was built with.

> I looked around the documentation but I didn't find any reference
> regarding=  the use of GCC plugins under windows.
> I only found some old posts on some forums saying  that it is
> possible to d= o that and that exist some old gcc versions (custom
> windows rebuild of GCC =
> 4.6.1 to use dragonegg as plugin) that can run plugins.
> 
> Substantially I'm writing just to ask:
> Can GCC plugins run on a windows build of GCC compiler (MinGW) ?

I suspect the answer is "you're the first person to try this in a
while; some things may need fixing" - but that's a guess :)

> If it is possible to do that, which is the correct way to build the
> plugin?

Good luck; I hope this is constructive.
Dave

Re: Plugin development under windows

[Joseph Myers]

On Mon, 27 Mar 2017, David Malcolm wrote:

> > Substantially I'm writing just to ask:
> > Can GCC plugins run on a windows build of GCC compiler (MinGW) ?
> 
> I suspect the answer is "you're the first person to try this in a
> while; some things may need fixing" - but that's a guess :)

If it's Windows host, the answer is: plugin support relies on dlopen, and 
on -rdynamic for plugins to access symbols from cc1/cc1plus.  No doubt it 
would be possible to add Windows host support, but it would require 
someone with a thorough understanding of the Windows DLL model and how it 
differs from ELF shared libraries to come up with and implement an 
appropriate design for Windows-host plugins in GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com

R: Plugin development under windows

[Davide Piombo]

Hi Dave,
thanks a lot for your ready answer.


> > The final platform target of the plugin is (unfortunately ;-))
> Windows
> > and = I tried to rebuild the plugin using MinGW compiler (both with
> > the Linux ver= sion as well by using MSYS2 and win-builds MinGW
> > compilers for windows) but=  the lack of POSIX includes breaks the
> > build.
> 
> (FWIW I've worked a lot with gcc plugins, but not on Windows).

OK, in this case you are THE EXPERT... ;-)

> 
> Sorry if I'm being obtuse here, but you say "the final platform target
> of the plugin is...Windows" - does that mean that
>  - the compiler (and thus the plugin within it) are going to run on
> Windows, and generate code for some (other?) system or that
>   - the compiler+plugin are going to run on some (other?) system, and
> generate code intended to run on Windows?
> 
> (AIUI the former case would mean that Windows is the *host*, the latter
> that it's the *target*).

Really sorry, my fault. First of all I had to clearly explain which is the environment...
The final application will be host on windows and will have an ARM M4 as target.
I'm working on the cross-compiler gcc-arm-none-eabi-6-2017-q1-update that I found on this site:
https://launchpad.net/gcc-arm-embedded
In the windows version of the toolchain the gcc plugin includes were deleted, I fixed this point but this didn't solve.
As you can see I also asked about the compilation of gcc-plugin there but my question is still pending...

As I already told you I successfully built the Linux version of the plugin, and then I tried the same build by using the MinGw cross compiler (on the same Linux Host).
The MinGW version is the same used by the arm-embedded toolchain build script to generate the windows version of the toolchain.
Using this configuration I tried to build the plugin, but the compilation failed as explained below. 



> 
> You say "the lack of POSIX includes breaks the build".
> Can you give more specifics on what goes wrong?  Maybe someone here can
> figure out a good workaround/bugfix.

Substantially I try to build the same plugin code that works on Linux using the MinGW compiler and the compiler stops with this error:
/home/user/Projects/sources/gcc-arm-none-eabi-6-2017-q1-update/lib/gcc/arm-none-abi/6.3.1/plugin/include/system.h:396:22: fatal error: sys/wait.h: No such file or directory

As first try I checked out the content of system.h file and I found that the include is in a pre-processor conditional block:

#ifdef HAVE_SYS_WAIT_H
#include <sys/wait.h>
#endif

And the same thing happens for other <sys/xxxx.h> include directives. 

I tried to force the behaviour of the build by manually change the auto-host.h file commenting out HAVE_SYS_WAIT_H and other pragmas in order to remove the dependencies from missing includes but after the exclusion on gmp.h in system.h the compilation goes very bad...


> 
> I believe that compiler plugins needs to be built using the same build,
> host and target configuration triplets as the compiler they're going to
> be embedded in was built with.
> 
Sorry, but this point is not really clear to me... 
Do you mean that I must use the same compiler used for the Linux plugin changing the build target from Linux to Windows and do not use the MinGW cross compiler?

> > I looked around the documentation but I didn't find any reference
> > regarding=  the use of GCC plugins under windows.
> > I only found some old posts on some forums saying  that it is
> possible
> > to d= o that and that exist some old gcc versions (custom windows
> > rebuild of GCC =
> > 4.6.1 to use dragonegg as plugin) that can run plugins.
> >
> > Substantially I'm writing just to ask:
> > Can GCC plugins run on a windows build of GCC compiler (MinGW) ?
> 
> I suspect the answer is "you're the first person to try this in a
> while; some things may need fixing" - but that's a guess :)

> 
> > If it is possible to do that, which is the correct way to build the
> > plugin?
> 
> Good luck; I hope this is constructive.
> Dave
Thanks again for your help
Davide

R: Plugin development under windows

[Davide Piombo]

Hi Joseph,
thanks a lot for your answer.

Sorry but it is not clear to me if the point is that the plugin development must include some windows-related code that I'm actually missing or if the problem is on the GCC side, that is inside GCC the code section that loads the dll, or part of it, is missing and it is still to be implemented.

Thanks in advance
Davide


> -----Messaggio originale-----
> Da: Joseph Myers [mailto:joseph@codesourcery.com]
> Inviato: lunedì 27 marzo 2017 17:57
> A: David Malcolm
> Cc: Davide Piombo; 'gcc@gcc.gnu.org'
> Oggetto: Re: Plugin development under windows
> 
> On Mon, 27 Mar 2017, David Malcolm wrote:
> 
> > > Substantially I'm writing just to ask:
> > > Can GCC plugins run on a windows build of GCC compiler (MinGW) ?
> >
> > I suspect the answer is "you're the first person to try this in a
> > while; some things may need fixing" - but that's a guess :)
> 
> If it's Windows host, the answer is: plugin support relies on dlopen,
> and on -rdynamic for plugins to access symbols from cc1/cc1plus.  No
> doubt it would be possible to add Windows host support, but it would
> require someone with a thorough understanding of the Windows DLL model
> and how it differs from ELF shared libraries to come up with and
> implement an appropriate design for Windows-host plugins in GCC.
> 
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: R: Plugin development under windows

[Joseph Myers]

On Mon, 27 Mar 2017, Davide Piombo wrote:

> Sorry but it is not clear to me if the point is that the plugin 
> development must include some windows-related code that I'm actually 
> missing or if the problem is on the GCC side, that is inside GCC the 
> code section that loads the dll, or part of it, is missing and it is 
> still to be implemented.

GCC only knows about how to dynamically load ELF shared libraries on a 
Unix-like operating system.  It does not know anything about whatever 
interfaces Windows provides to load DLLs.

GCC assumes a shared library can access symbols dynamically exported by 
its internal cc1 and cc1plus executables.  I've heard that DLLs work 
differently (without an equivalent of -rdynamic), such that for a DLL to 
access GCC-internal functions the whole of cc1/cc1plus would instead need 
to be moved into a DLL.

This requires someone with expertise on the relevant Windows facilities 
(and probably significant cross-platform expertise as well, since you need 
to adapt the build system and plugin support to do the required things for 
each platform) to implement the support in GCC for plugins on Windows 
host.

-- 
Joseph S. Myers
joseph@codesourcery.com

R: R: Plugin development under windows

[Davide Piombo]

Hi Joseph,
OK, thanks, now it clear to me your point.
I do not know what the GCC plugin code really contains and I trust you when you say that GCC plugin section is not ready to handle dll on windows.
But I still have two points that are not clear to me:

1- I found some historical references about the fact that exists a porting of dragonegg GCC plugin to Windows (dated 2011 running on GCC 4.6.1) that, following the description provided, has been obtained simply changing some parts of the GCC configure script. I tried to follow the instructions reported updating the configure script but without success.
Does the problem is a different implementation of GCC plugin handling code in actual version?
You can find the references of the dragonegg porting here:
https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc

2- It is my opinion that there are some other problems than the dll handling. What I found trying to rebuild the plugin on windows is that the plugin doesn't build at all, and that the errors are not related to dll handling features.
This drives me to think that in order to build a plugin where Windows is the Host for a GCC build it is necessary to do some other changes.
What do you think about that?

Thanks in advance
Davide
      

> -----Messaggio originale-----
> Da: Joseph Myers [mailto:joseph@codesourcery.com]
> Inviato: lunedì 27 marzo 2017 18:56
> A: Davide Piombo
> Cc: David Malcolm; 'gcc@gcc.gnu.org'
> Oggetto: Re: R: Plugin development under windows
> 
> On Mon, 27 Mar 2017, Davide Piombo wrote:
> 
> > Sorry but it is not clear to me if the point is that the plugin
> > development must include some windows-related code that I'm actually
> > missing or if the problem is on the GCC side, that is inside GCC the
> > code section that loads the dll, or part of it, is missing and it is
> > still to be implemented.
> 
> GCC only knows about how to dynamically load ELF shared libraries on a
> Unix-like operating system.  It does not know anything about whatever
> interfaces Windows provides to load DLLs.
> 
> GCC assumes a shared library can access symbols dynamically exported by
> its internal cc1 and cc1plus executables.  I've heard that DLLs work
> differently (without an equivalent of -rdynamic), such that for a DLL
> to access GCC-internal functions the whole of cc1/cc1plus would instead
> need to be moved into a DLL.
> 
> This requires someone with expertise on the relevant Windows facilities
> (and probably significant cross-platform expertise as well, since you
> need to adapt the build system and plugin support to do the required
> things for each platform) to implement the support in GCC for plugins
> on Windows host.
> 
> --
> Joseph S. Myers
> joseph@codesourcery.com

Re: R: R: Plugin development under windows

[Trevor Saunders]

On Tue, Mar 28, 2017 at 07:51:47AM +0000, Davide Piombo wrote:
> Hi Joseph,
> OK, thanks, now it clear to me your point.
> I do not know what the GCC plugin code really contains and I trust you when you say that GCC plugin section is not ready to handle dll on windows.
> But I still have two points that are not clear to me:
> 
> 1- I found some historical references about the fact that exists a porting of dragonegg GCC plugin to Windows (dated 2011 running on GCC 4.6.1) that, following the description provided, has been obtained simply changing some parts of the GCC configure script. I tried to follow the instructions reported updating the configure script but without success.
> Does the problem is a different implementation of GCC plugin handling code in actual version?
> You can find the references of the dragonegg porting here:
> https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc
> 
> 2- It is my opinion that there are some other problems than the dll handling. What I found trying to rebuild the plugin on windows is that the plugin doesn't build at all, and that the errors are not related to dll handling features.
> This drives me to think that in order to build a plugin where Windows is the Host for a GCC build it is necessary to do some other changes.
> What do you think about that?

From your errors about posix headers, and since gcc also uses those I
suspect your mingw enviroment is not setup correctly.

Trev

> 
> Thanks in advance
> Davide
>       
> 
> > -----Messaggio originale-----
> > Da: Joseph Myers [mailto:joseph@codesourcery.com]
> > Inviato: lunedì 27 marzo 2017 18:56
> > A: Davide Piombo
> > Cc: David Malcolm; 'gcc@gcc.gnu.org'
> > Oggetto: Re: R: Plugin development under windows
> > 
> > On Mon, 27 Mar 2017, Davide Piombo wrote:
> > 
> > > Sorry but it is not clear to me if the point is that the plugin
> > > development must include some windows-related code that I'm actually
> > > missing or if the problem is on the GCC side, that is inside GCC the
> > > code section that loads the dll, or part of it, is missing and it is
> > > still to be implemented.
> > 
> > GCC only knows about how to dynamically load ELF shared libraries on a
> > Unix-like operating system.  It does not know anything about whatever
> > interfaces Windows provides to load DLLs.
> > 
> > GCC assumes a shared library can access symbols dynamically exported by
> > its internal cc1 and cc1plus executables.  I've heard that DLLs work
> > differently (without an equivalent of -rdynamic), such that for a DLL
> > to access GCC-internal functions the whole of cc1/cc1plus would instead
> > need to be moved into a DLL.
> > 
> > This requires someone with expertise on the relevant Windows facilities
> > (and probably significant cross-platform expertise as well, since you
> > need to adapt the build system and plugin support to do the required
> > things for each platform) to implement the support in GCC for plugins
> > on Windows host.
> > 
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com

R: R: R: Plugin development under windows

[Davide Piombo]

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.

I tried to link by using the libgcc.a file included in the Arm cross compiler directory but the compiler complains about the different release (Cygwin gcc is 5.4.0 while ARM cross compiler is 6.3.1) and, as far as I know, this problem can be solved only using the same compiler version for build and libraries...

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. 
Just for completeness missing symbols are:
register_scoped_attributes(attribute_spec const*, char const*)
global_dc
global_options
register_callback

Following Joseph's reply I also had a look at gcc plugin source code, effectively there are no OS related conditional build pragmas and the code does not contain dedicated sections to handle the load and unload of dll under Windows.

Unless somebody has a good idea on how to solve these issues I think I will stop my investigations...

I wish to thank all of you for your time and for your help.
I just want to ask to gcc plugin site maintainers to add a note on the site about the fact that actually plugins cannot run on Windows, I think it is an useful info... ;-)

Thanks again to everybody

Davide




> -----Messaggio originale-----
> Da: Trevor Saunders [mailto:tbsaunde@tbsaunde.org]
> Inviato: mercoledì 29 marzo 2017 01:09
> A: Davide Piombo
> Cc: 'Joseph Myers'; David Malcolm; 'gcc@gcc.gnu.org'
> Oggetto: Re: R: R: Plugin development under windows
> 
> On Tue, Mar 28, 2017 at 07:51:47AM +0000, Davide Piombo wrote:
> > Hi Joseph,
> > OK, thanks, now it clear to me your point.
> > I do not know what the GCC plugin code really contains and I trust
> you when you say that GCC plugin section is not ready to handle dll on
> windows.
> > But I still have two points that are not clear to me:
> >
> > 1- I found some historical references about the fact that exists a
> porting of dragonegg GCC plugin to Windows (dated 2011 running on GCC
> 4.6.1) that, following the description provided, has been obtained
> simply changing some parts of the GCC configure script. I tried to
> follow the instructions reported updating the configure script but
> without success.
> > Does the problem is a different implementation of GCC plugin handling
> code in actual version?
> > You can find the references of the dragonegg porting here:
> > https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc
> >
> > 2- It is my opinion that there are some other problems than the dll
> handling. What I found trying to rebuild the plugin on windows is that
> the plugin doesn't build at all, and that the errors are not related to
> dll handling features.
> > This drives me to think that in order to build a plugin where Windows
> is the Host for a GCC build it is necessary to do some other changes.
> > What do you think about that?
> 
> From your errors about posix headers, and since gcc also uses those I
> suspect your mingw enviroment is not setup correctly.
> 
> Trev
> 
> >
> > Thanks in advance
> > Davide
> >
> >
> > > -----Messaggio originale-----
> > > Da: Joseph Myers [mailto:joseph@codesourcery.com]
> > > Inviato: lunedì 27 marzo 2017 18:56
> > > A: Davide Piombo
> > > Cc: David Malcolm; 'gcc@gcc.gnu.org'
> > > Oggetto: Re: R: Plugin development under windows
> > >
> > > On Mon, 27 Mar 2017, Davide Piombo wrote:
> > >
> > > > Sorry but it is not clear to me if the point is that the plugin
> > > > development must include some windows-related code that I'm
> > > > actually missing or if the problem is on the GCC side, that is
> > > > inside GCC the code section that loads the dll, or part of it, is
> > > > missing and it is still to be implemented.
> > >
> > > GCC only knows about how to dynamically load ELF shared libraries
> on
> > > a Unix-like operating system.  It does not know anything about
> > > whatever interfaces Windows provides to load DLLs.
> > >
> > > GCC assumes a shared library can access symbols dynamically
> exported
> > > by its internal cc1 and cc1plus executables.  I've heard that DLLs
> > > work differently (without an equivalent of -rdynamic), such that
> for
> > > a DLL to access GCC-internal functions the whole of cc1/cc1plus
> > > would instead need to be moved into a DLL.
> > >
> > > This requires someone with expertise on the relevant Windows
> > > facilities (and probably significant cross-platform expertise as
> > > well, since you need to adapt the build system and plugin support
> to
> > > do the required things for each platform) to implement the support
> > > in GCC for plugins on Windows host.
> > >
> > > --
> > > Joseph S. Myers
> > > joseph@codesourcery.com

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

[Pedro Alves]

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

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

[Davide Piombo]

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