mingw32 DLLs, threads and exceptions HOWTO

mingw32 DLLs, threads and exceptions HOWTO

[Thomas Pfaff]

Dear all,

this is a summary that should help users to have thread safe exception
handling over DLL exported functions.
If you don't care about c++ exceptions you can stop reading here.

The first time i struggled with c++ exceptions was when i tried to throw an
exception in a dll exported function where the exception handler resides in
the program module.
Instead of catching the exception the program stopped with an abnormal
termination.
The reason was that the exception code is in libgcc.a. Since this is a
static library the code and some static variables are both in the dll and in
the program module, each module runs in its own context.
It was Franco Bez that pointed me in the right direction, that is convert
libgcc.a into a dll.

That done i tried to build the pthreads-win32 library, but some tests failed
with an access violation. Due to the fact that the dll was not build
was -mthreads support, eh_context_static instead of eh_context_specific (the
mthreads version) was used for exception handling.
I did a rebuild of the gcc dll with -mthreads, now all tests are passed
(except a nonportable exception test that relies on a MSVC feature).

To build the gcc dll i did the following steps.

1. create a temporary directory libgcc
2. copy libgcc.a from gcc-2.95.2\lib\gcc-lib\i386-mingw32\gcc-2.95.2 to that
directory
3. ar -x libgcc.a
4. create a directory tmp and move __main.o, _exit.o and __dummy.o in that
directory
5. build the dll
gcc -shared -mthreads -o gcc.dll *.o
strip gcc.dll
Move this dll into your gcc\bin directory
6. Move _chkstk.o and frame.o to the tmp directory, otherwise you break the
builtin alloca.
7. Build the import library libgcc.a
dllwrap --export-all --dllname=gcc.dll --output-def=libgcc.def --output-lib=
libgcc.a *.o
ar -q libgcc.a tmp/*.o
strip --strip-debug libgcc.a
ranlib libgcc.a
8. save your old libgcc.a, copy the new libgcc.a into
gcc-2.95.2\lib\gcc-lib\i386-mingw32\gcc-2.95.2

I am using gcc-2.95.2-1 with Mumits patched binutils-19990818-1and msvcrt
runtime-2000-03-27.
I don't know if this is still required with the current binutils and gcc
since i have seen no sources until now.

I believe that these steps are at least necessary if you are trying to use
the pthreads-win32 library (which is required if you want to use gtk+ on
win32).
They will make mingw32 a real replacement for MSVC (at least for me).

What is left:

1. Include the mingwm10.dll function into the gcc.dll to have only one dll
left.
2. make -mthreads and -fnative-struct default compiler options.
3. convert libstdc++ to a dll by adding the declspec dllexport and dllimport
to every class definition.

Regards,
    Thomas

Re: mingw32 DLLs, threads and exceptions HOWTO

[Ross Johnson]

Hi Thomas,

This is great news! I followed your instructions
for the same result. Brilliant!

As you noted, the exception1.c test fails. For some reason
catch(...) isn't catching the deliberate zero divide exception.
I've substituted a different exception, which passes. (The
test simply confirms that the redefinition of catch in
pthread.h works.)

Your message will be in the FAQ.

Cheers and thanks.
Ross

Thomas Pfaff wrote:
> 
> Dear all,
> 
> this is a summary that should help users to have thread safe exception
> handling over DLL exported functions.
> If you don't care about c++ exceptions you can stop reading here.
> 
> The first time i struggled with c++ exceptions was when i tried to throw an
> exception in a dll exported function where the exception handler resides in
> the program module.
> Instead of catching the exception the program stopped with an abnormal
> termination.
> The reason was that the exception code is in libgcc.a. Since this is a
> static library the code and some static variables are both in the dll and in
> the program module, each module runs in its own context.
> It was Franco Bez that pointed me in the right direction, that is convert
> libgcc.a into a dll.
> 
> That done i tried to build the pthreads-win32 library, but some tests failed
> with an access violation. Due to the fact that the dll was not build
> was -mthreads support, eh_context_static instead of eh_context_specific (the
> mthreads version) was used for exception handling.
> I did a rebuild of the gcc dll with -mthreads, now all tests are passed
> (except a nonportable exception test that relies on a MSVC feature).
> 
> To build the gcc dll i did the following steps.
> 
> 1. create a temporary directory libgcc
> 2. copy libgcc.a from gcc-2.95.2\lib\gcc-lib\i386-mingw32\gcc-2.95.2 to that
> directory
> 3. ar -x libgcc.a
> 4. create a directory tmp and move __main.o, _exit.o and __dummy.o in that
> directory
> 5. build the dll
> gcc -shared -mthreads -o gcc.dll *.o
> strip gcc.dll
> Move this dll into your gcc\bin directory
> 6. Move _chkstk.o and frame.o to the tmp directory, otherwise you break the
> builtin alloca.
> 7. Build the import library libgcc.a
> dllwrap --export-all --dllname=gcc.dll --output-def=libgcc.def --output-lib=
> libgcc.a *.o
> ar -q libgcc.a tmp/*.o
> strip --strip-debug libgcc.a
> ranlib libgcc.a
> 8. save your old libgcc.a, copy the new libgcc.a into
> gcc-2.95.2\lib\gcc-lib\i386-mingw32\gcc-2.95.2
> 
> I am using gcc-2.95.2-1 with Mumits patched binutils-19990818-1and msvcrt
> runtime-2000-03-27.
> I don't know if this is still required with the current binutils and gcc
> since i have seen no sources until now.
> 
> I believe that these steps are at least necessary if you are trying to use
> the pthreads-win32 library (which is required if you want to use gtk+ on
> win32).
> They will make mingw32 a real replacement for MSVC (at least for me).
> 
> What is left:
> 
> 1. Include the mingwm10.dll function into the gcc.dll to have only one dll
> left.
> 2. make -mthreads and -fnative-struct default compiler options.
> 3. convert libstdc++ to a dll by adding the declspec dllexport and dllimport
> to every class definition.
> 
> Regards,
>     Thomas

Re: mingw32 DLLs, threads and exceptions HOWTO

[Thomas Pfaff]

Hello Ross,

catch(...) does not work simply because no exception is raised (LINUX won't
either). This is a MSVC runtime feature.

You have to install a SIGFPE signal handler and use setjmp/longjmp to get
FP exceptions.

Regards,
    Thomas

> Ross Johnson wrote
>
> As you noted, the exception1.c test fails. For some reason
> catch(...) isn't catching the deliberate zero divide exception.
> I've substituted a different exception, which passes. (The
> test simply confirms that the redefinition of catch in
> pthread.h works.)
>

Re: [Mingw-users] mingw32 DLLs, threads and exceptions HOWTO

[Paul Sokolovsky]

Hello Thomas,

Thomas Pfaff <tpfaff@gmx.net> wrote on Thursday, December 07, 2000:

TP> It was Franco Bez that pointed me in the right direction, that is convert
TP> libgcc.a into a dll.

    Can you point me to any normal GNU-based system which has shared
libgcc? If not, I don't think it's valid for win32 either.


TP> 1. Include the mingwm10.dll function into the gcc.dll to have only one dll
TP> left.
TP> 2. make -mthreads and -fnative-struct default compiler options.
TP> 3. convert libstdc++ to a dll by adding the declspec dllexport and dllimport
TP> to every class definition.

    Alternative proposal:
1) Partition libgcc into C and C++ parts (consider generic exception
handling C++ burden).
2) Leave the former in peace, stuff the latter into libstdc++ along
the mingwm10 magic.
3) Convert it all to dll without unneeded (unless proven otherwise)
declspec magic.


    Next gcc package alpha/beta will contain at least 3) (i.e. shared
libstdc++), of course if I won't find flaw with it, so far I didn't. I
don't use C++ exception currently, so I'm rather indifferent to 1) and
2), if you're interested, your help welcome. Ideally, it should be
shell script which will produce that libstdc++.dll from static libs
and/or their object.


TP> Regards,
TP>     Thomas


--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135

Re: [Mingw-users] mingw32 DLLs, threads and exceptions HOWTO

[Thomas Pfaff]

Hi Paul,

> TP> It was Franco Bez that pointed me in the right direction, that is
convert
> TP> libgcc.a into a dll.
>
>     Can you point me to any normal GNU-based system which has shared
> libgcc? If not, I don't think it's valid for win32 either.
>

Any normal GNU-based system has shared libraries. It is only the main module
that will be linked against libgcc.a. Due to the design of DLLs every DLL
that is compiled with gcc is linked against libgcc.a. Libgcc.a contains
static variables for exception handling. Every module will include these and
make exception handling work only in this module. You must  rewrite
libgcc2.c in a way that all statics are removed and replaced by variables in
shared memory, link only static or find a way to make real shared libs to
make exception handling work as expected.

I do not see any reason why libgcc must always be static. I had never had
any trouble with the gcc.dll. If someone cares about create a compiler
switch to select between static and shared libgcc.

>
> TP> 1. Include the mingwm10.dll function into the gcc.dll to have only one
dll
> TP> left.
> TP> 2. make -mthreads and -fnative-struct default compiler options.
> TP> 3. convert libstdc++ to a dll by adding the declspec dllexport and
dllimport
> TP> to every class definition.
>
>     Alternative proposal:
> 1) Partition libgcc into C and C++ parts (consider generic exception
> handling C++ burden).

Currently all this eh stuff is in libgcc2.c. I don't see any reason to break
this only for win32. Consider that you can have c++ code that does not
require libstdc++. There is no performance penalty if you don't use
exceptions.

The mingwm10 must be build as a dll, because it use features the from
DllMain (thread detach ) to cleanup eh after thread termination (free some
memory).
If this would be included in a gcc.dll there is no more need for -mthreads
since exceptions are thread safe by default, and the gcc dll will use the
right get_eh_context call (eh_context_specific).

>     Next gcc package alpha/beta will contain at least 3) (i.e. shared
> libstdc++), of course if I won't find flaw with it, so far I didn't. I
> don't use C++ exception currently, so I'm rather indifferent to 1) and
> 2), if you're interested, your help welcome. Ideally, it should be
> shell script which will produce that libstdc++.dll from static libs
> and/or their object.

I would spend some time to make a shell script that does the libgcc.a to dll
conversion and that will include the mingwm10 code for those who are
interested.
If you change your mind about a libgcc.dll i would also take a look at
Makefile.in to get a dll by default when gcc is configured
with --enable-threads (or implement a new configure option).
The libstdc++ dll is only nice to have but low on priority.

I would be very interested in getting the latest sources for gcc and
binutils but have not seen any 'till now. Currently i am using Mumits
gcc-2.95.2-1.

RE: mingw32 DLLs, threads and exceptions HOWTO

[Bossom, John]

Just a technical note, you CAN get the Win32 environment to deal with
hardware exceptions by registering a handler with the Win32 Structured
Exception Handler and have that map the hardware exceptions to some
C++ exception and then throw it.

However, as Thomas pointed out, indirectly, on UNIX, the C++ mechanism
does not, and will not, handle hardware exceptions. 


-----Original Message-----
From: Thomas Pfaff [ mailto:tpfaff@gmx.net ]
Sent: December 11, 2000 4:21 AM
To: rpj@ise.canberra.edu.au
Cc: pthreads-win32@sources.redhat.com
Subject: Re: mingw32 DLLs, threads and exceptions HOWTO


Hello Ross,

catch(...) does not work simply because no exception is raised (LINUX won't
either). This is a MSVC runtime feature.

You have to install a SIGFPE signal handler and use setjmp/longjmp to get
FP exceptions.

Regards,
    Thomas

> Ross Johnson wrote
>
> As you noted, the exception1.c test fails. For some reason
> catch(...) isn't catching the deliberate zero divide exception.
> I've substituted a different exception, which passes. (The
> test simply confirms that the redefinition of catch in
> pthread.h works.)
>