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: Eclipse vs gij/libgcj, unit-at-a-time, -O2 and -O

From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
To: Jeff Sturm <jsturm at one-point dot com>
Cc: Mark Wielaard <mark at klomp dot org>,java at gcc dot gnu dot org
Date: Wed, 3 Dec 2003 13:55:19 +1300
Subject: Re: Eclipse vs gij/libgcj, unit-at-a-time, -O2 and -O
References: <Pine.LNX.4.44.0311291507390.19585-100000@ops2.one-point.com>

On Nov 30, 2003, at 9:40 AM, Jeff Sturm wrote:

So the eclipse code calls the single-argument Class.forName(), which walks the stack frame to find a loader and fails, presumably because _Jv_StartOfInterpreter and _Jv_EndOfInterpreter no longer surround the _Jv_InterpMethod::run method in generated code.
00000680 T _Z22_Jv_StartOfInterpreterv
00000690 T _Z20_Jv_EndOfInterpreterv
000006e0 T _ZN16_Jv_InterpMethod3runEPvP7ffi_raw
I guess we could force interpret.o to be built with -fno-unit-at-a-time
unless someone has a better idea.

My stack-trace patch will fix this. It uses the DWARF unwinder to detect interpreter frames, and the _Jv_StartOfInterpreter etc will go away.

Regards

Bryce.

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