public inbox for pthreads-win32@sourceware.org
 help / color / mirror / Atom feed
From: "Thomas Pfaff" <tpfaff@gmx.net>
To: "Paul Sokolovsky" <paul-ml@is.lg.ua>
Cc: <mingw-users@lists.sourceforge.net>, <pthreads-win32@sources.redhat.com>
Subject: Re: [Mingw-users] mingw32 DLLs, threads and exceptions HOWTO
Date: Thu, 14 Dec 2000 01:48:00 -0000	[thread overview]
Message-ID: <003d01c065b2$f75a7ae0$69856286@pcs.ditec.de> (raw)
In-Reply-To: <15977.001213@is.lg.ua>

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.

      reply	other threads:[~2000-12-14  1:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-12-07  2:15 Thomas Pfaff
2000-12-10  6:08 ` Ross Johnson
2000-12-11  1:27   ` Thomas Pfaff
2000-12-13 13:26 ` [Mingw-users] " Paul Sokolovsky
2000-12-14  1:48   ` Thomas Pfaff [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='003d01c065b2$f75a7ae0$69856286@pcs.ditec.de' \
    --to=tpfaff@gmx.net \
    --cc=mingw-users@lists.sourceforge.net \
    --cc=paul-ml@is.lg.ua \
    --cc=pthreads-win32@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).