This is the mail archive of the java@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: bad news re: mingw exceptions



Jeff Sturm <jsturm@one-point.com> writes:
> On 27 Feb 2002, Adam Megacz wrote:
> > Ugh, this is really bad; C++ exceptions work, Java exceptions don't

> These aren't really c++ exceptions in your example.  Because you're
> compiling CNI, g++ is impersonating Java exceptions.

Huh, very strange -- if the same code gets emitted, why would the two
programs behave differently?

At compile time, how does g++ know that test.cc will get linked
against Java code later on (and hence should emit code for Java
exceptions, not C++ exceptions)?

When I tried to link without -lsupc++ I got unresolved symbols --
doesn't this mean it's trying to call C++ exceptioning stuff?

If the Java and C++ exceptioning mechanisms are totally different, has
anything changed in the Java ones? What files deal with Java
exceptions in the front end? I'll try rolling them back to 12-Dec and
see what happens. I assume that only exception.cc is relevant in the
library, and I've tried rolling that back with no success.


> > This stuff worked in the 12-Dec tree; has anything changed in
> > exception handling since then? I tried this same program in my old
> > 12-Dec tree and it works.

> You are linking both with -mthreads, right?  So _CRT_MT is non-zero?

I #undef MINGW32_SUPPORTS_MT_EH in gthr-win32.h instead (same effect,
except that there's no DLL to clean up the per-thread TLS garbage, but
it's no big deal since that's only 24 bytes per thread or so).

I found the original patch that created '-mthreads' in 1999, and it
doesn't appear to impact emitted code, so this hack should be safe.

In the long term I'm going to pester the mingw/gcc folks for a way to
tell the compiler that you're not going to link in mingwthr.dll, but
you still want thread-safe exceptions. Then I'll just manually invoke
the gthread dtor in the Win32 Thread.$finit().

I also tried disabling the finalizer thread, so the program is
entirely single-threaded, and it still crashes -- so this is (sadly)
distinct from the inter-thread-exceptioning problems I've seen before.


  - a


-- 
"If I put copyrighted material into the 'chewy nougat center', I can
 claim the crunchy chocolate coating is an 'Access Control
 Mechanism'."                                     --lynx_user_abroad

Why Windows NT/2k/XP is unreliable: www.zappadoodle.com


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