Wrestling with exceptions on win32 gcj 4.1

[Darius]

Hello, Ranjit,
thanks for the patch!

It removes the segfault as my patches did:
http://gcc.gnu.org/ml/java/2006-02/msg00066.html

That is because _Unwind_Backtrace() is not called anymore,
which was segfaulting.

However, the bigger problem remains.

The functions:
_Jv_StackTrace::GetClassContext()
_Jv_StackTrace::GetCallingClass()
_Jv_StackTrace::GetFirstNonSystemClassLoader()

do not return correct information because fallback_backtrace()
doesn't fill the start_ip in _Jv_StackFrame, and this is needed
by _Jv_StackTrace::ClassForFrame() to do the lookup.

The consequence of all this is that SecurityManager stuff
and Class.forName(String) don't work :(

Is there any way to fill start_ip with correct method start address
using SJLJ exceptions?

Thanks,
-- dpr

----- Original Message ----- 
From: "Ranjit Mathew" <rmathew@gmail.com>
To: "tHE DPR" <dpr@aha.lt>
Cc: "GCJ" <java@gcc.gnu.org>
Sent: Thursday, April 06, 2006 5:44 PM
Subject: Re: Wrestling with exceptions on win32 gcj 4.1

> 
> The problem is that _Unwind_Backtrace() should not be called
> for non-DWARF-2 EH (i.e. SJLJ) targets:
> 
>  http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00472.html
> 
> You need something like the attached patch to prevent this
> situation. See if it resolves your segfault.
> 
> Note that you *still* won't get proper method names in
> stack traces - see the _Jv_StackTrace::GetStackTraceElements()
> method in "libjava/stacktrace.cc", which just prints the
> instruction pointers (IPs) in hex for SJLJ targets.
> 
> The best option is to use DWARF-2 EH for Windows.
> (Though this does not work if you're trying to throw an
> exception across code that is not using DWARF-2 EH.
> For example, in a Windows GUI callback function, you
> cannot throw an exception and then hope to catch it
> in your event loop.)
> 
> HTH,
> Ranjit.