This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ATTN Windows Users: RFC - GCJ/MinGW and Thread-Safe Exception Handling


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[Ref.: http://gcc.gnu.org/ml/java/2006-07/msg00014.html]

Ranjit Mathew wrote:
> On 7/4/06, Danny Smith <dannysmith@clear.net.nz> wrote:
>> Would this not work?
>>
>> (1) Put this into a object file of its own and add it to link spec as a
>> 'startup' object so it
>> overrides the static libmingw.a library version.
> 
> Sorry for asking a basic question, but how do you specify
> something as a "startup" object? I looked at the ld manual
> but couldn't immediately locate this information.

I misunderstood you - I think you meant the "startfile"
GCC spec string.

Thank you for suggesting it. I found a ready-made object file
like this in "crtmt.o" that the MinGW runtime already provides
(but GCC doesn't seem to use it AFAICT). This way I do not have
to worry about where to put this startup object file and how to
make GCC locate it during linking.

The attached patch implements your suggestion and resolves
the build issue while avoiding the dependency on mingwm10.dll.

It was tested via:

  1. an i686-pc-linux-gnu to i686-pc-mingw32 cross compiler,
  2. an i686-pc-mingw32 crossed-native compiler on i686-pc-linux-gnu,
  3. an i686-pc-linux-gnu native compiler.

OK to apply?

(I notice that there are some spurious differences between
the existing "configure" and the one regenerated by FSF
autoconf 2.59. Specifically these relate to using Xlib.h
v/s Intrinsic.h for some tests. I think this is an artifact
of using something like a patched autoconf 2.59 to generate
the existing "configure".)


>> I don't know why I'm suggesting this. I have never liked the foolery in
>> win32.cc and wopuld be glad to see it removed.
> 
> Exactly! I would have thought that you of all people would
> be in favour of removing this kludge.

And you have now been instrumental in perpetuating this
"foolery". :-P

Thanks,
Ranjit.

- --
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://rmathew.com/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEqjeMYb1hx2wRS48RAmOuAJwNPVXsdlLDrxd4jrSDrT9CCLWrqgCfenyP
CW9MICdu3aVoACm1efkYY6Q=
=EcoU
-----END PGP SIGNATURE-----
Index: ChangeLog
from  Ranjit Mathew  <rmathew@gcc.gnu.org>
	Danny Smith  <dannysmith@users.sourceforge.net>

	* libgcj.spec.in: Use THREADSTARTFILESPEC to affect the spec for
	startfile.
	* configure.ac: Allow targets to affect the spec for startfile
	by specifying a THREADSTARTFILESPEC variable.  Define this for
	the win32 threads package to include crtmt.o.
	* configure: Regenerate.
	* win32.cc (_CRT_MT): Remove definition.
	(__mingwthr_key_dtor): Likewise.

Index: libgcj.spec.in
===================================================================
--- libgcj.spec.in	(revision 115171)
+++ libgcj.spec.in	(working copy)
@@ -3,6 +3,9 @@
 # It is used to specify the standard libraries we need in order
 # to link with libgcj.
 #
+%rename startfile startfileorig
+*startfile: @THREADSTARTFILESPEC@ %(startfileorig)
+
 %rename lib liborig
 *lib: @LD_START_STATIC_SPEC@ -lgcj @LD_FINISH_STATIC_SPEC@ -lm @LIBICONV@ @GCSPEC@ @THREADSPEC@ @ZLIBSPEC@ @SYSTEMSPEC@ %(libgcc) %(liborig)
 
Index: configure.ac
===================================================================
--- configure.ac	(revision 115171)
+++ configure.ac	(working copy)
@@ -783,6 +783,7 @@ THREADINCS=
 THREADDEPS=
 THREADH=
 THREADSPEC=
+THREADSTARTFILESPEC=
 case "$THREADS" in
  posix)
     case "$host" in
@@ -834,6 +835,18 @@ case "$THREADS" in
 
  win32)
     THREADH=win32-threads.h
+    THREADCXXFLAGS=-mthreads
+    # We need thread-safe exception handling so _CRT_MT should be set to 1.
+    # But we do not want the executables created to be dependent on
+    # mingwm10.dll which provides a __mingwthr_key_dtor() that cleans up
+    # exception handling contexts.  The following kludge achieves this effect
+    # and causes a dummy __mingwthr_key_dtor() to be linked in from
+    # libmingw32.a.  This causes a memory leak of about 24 bytes per thread.
+    #
+    # FIXME: In Java we are able to detect thread death at the end of
+    # Thread.run() so we should be able to clean up the exception handling
+    # contexts ourselves.
+    THREADSTARTFILESPEC='crtmt%O%s'
     ;;
 
  none)
@@ -845,6 +858,7 @@ AC_SUBST(THREADLIBS)
 AC_SUBST(THREADINCS)
 AC_SUBST(THREADDEPS)
 AC_SUBST(THREADSPEC)
+AC_SUBST(THREADSTARTFILESPEC)
 AC_SUBST(THREADLDFLAGS)
 AC_SUBST(THREADCXXFLAGS)
 AM_CONDITIONAL(USING_POSIX_THREADS, test "$THREADS" = posix)
Index: win32.cc
===================================================================
--- win32.cc	(revision 115171)
+++ win32.cc	(working copy)
@@ -288,21 +288,6 @@ _Jv_platform_nanotime ()
   return _Jv_platform_gettimeofday () * 1000LL;
 }
 
-// The following definitions "fake out" mingw to think that -mthreads
-// was enabled and that mingwthr.dll was linked. GCJ-compiled
-// applications don't need this helper library because we can safely
-// detect thread death (return from Thread.run()).
-
-int _CRT_MT = 1;
-
-extern "C" int
-__mingwthr_key_dtor (DWORD, void (*) (void *))
-{
-  // FIXME: for now we do nothing; this causes a memory leak of
-  //        approximately 24 bytes per thread created.
-  return 0;
-}
-
 static bool dirExists (LPCTSTR dir)
 {
   DWORD dwAttrs = ::GetFileAttributes (dir);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]