Debugging libgcj on cygwin

Tue Jul 1 03:37:00 GMT 2003

On 2003年6月30日, Thomas Pfaff wrote:
> An attempt to load and run this class via _Jv_InterpMethod::run is made.
> A call to java::lang::Thread *thread = java::lang::Thread::currentThread
> is made which returns NULL since the main thread is not initialized yet
> (a call to _Jv_AttachCurrentThread will be later done in _Jv_RunMain,
> the backtrace above shows that it is still in _Jv_CreateJavaVM).

Good analysis, thanks.
> What makes me wonder is that this seems to happen only on cygwin.

You'd expect to see it anywhere with static linking, but, for whatever
reason Cygwin seems to be choosing a default file.encoding of ASCII
instead of the usual 8859_1. The latter encoder tends to always link in
static builds.
This patch from mainline may help:
2003年06月12日 Andrew Haley <aph@redhat.com>
 * prims.cc (catch_segv): Create exception in handler.
 (catch_fpe): Likewise.
 (_Jv_divI, _Jv_remI, _Jv_divJ, _Jv_remJ): Likewise.
 (_Jv_ThrowSignal): Remove.
 * include/x86_64-signal.h (INIT_SEGV): Delete reference to nullp.
 * include/default-signal.h (INIT_SEGV, INIT_FPE): Delete reference
 to nullp and arithexception.
 * include/dwarf2-signal.h (INIT_SEGV, INIT_FPE): Likewise.
 * include/i386-signal.h (INIT_SEGV, INIT_FPE): Likewise.
 * include/s390-signal.h (INIT_SEGV, INIT_FPE): Likewise.
 * include/sparc-signal.h (INIT_SEGV, INIT_FPE): Likewise.
 * include/win32-signal.h (INIT_SEGV, INIT_FPE): Likewise.
If so, backporting Andrew's patch to 3.3 is one solution.
Jeff