RE: mingw32 DLLs, threads and exceptions HOWTO

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.)
>

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: 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

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