Re: [kaffe] (Partial) success with RC1 under Linux/PPC
On Sun, 2002-06-02 at 17:33, Jim Pick wrote: Cool. I don't have Linux on my iBook yet, so I couldn't test it. :-) I'll look at the AWT errors (I haven't done any AWT testing). I want to put your test results into the RELEASE-NOTES file - which engine did you compile with? (I'm guessing intrp) Yep, intrp - the only one available for linux-ppc at the moment. I didn't specify any other options (--with-staticvm, etc.), just did a plain './configure make make check'. I'll have a try with all other options, though. Cheers, Carlos ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Can't compile with gcc 3.1
Hi, I've checked out the cvs today, it compiles well with gcc 2.9.x but I can't compile it with gcc 3.1, this is my error output: Remove -I/usr/local/include from configure.in. You should not explicitly add system include dirs to the include search path (-I/usr/include or -I/usr/local/include). Bye, Gwenole. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] (Partial) success with RC1 under Linux/PPC
On 3 Jun 2002, Carlos Valiente wrote: Yep, intrp - the only one available for linux-ppc at the moment. Hadn't EGP wrote a JIT back-end? http://egp.free.fr/port-kaffe/port-kaffe-0.2.html Unfortunately, we know what happened, so. :-/ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] make check results?
Hi, I made the check on couple of different CVS version and the officially released 1.0.6 and all of them have most of the post-compilation tests FAIL. example: PASS: ThreadStop.java FAIL: DeadThread.java FAIL: tthrd1.java FAIL: SoInterrupt.java FAIL: sysdepCallMethod.java FAIL: DosTimeVerify.java PASS: ZipVerify.java PASS: TestNative.java == 96 of 104 tests failed == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Interrupt make[1]: *** [check-recursive] Interrupt make: *** [check-recursive] Interrupt Is this normal, or am I doing something wrong? -- Alexander Popov Team Leader RTOSJVM ProSyst Bulgaria [EMAIL PROTECTED] mobile: +35987663193 icq: 29207350 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Can't compile with gcc 3.1- now works
On Monday 03 June 2002 15:06, Gwenole Beauchesne wrote: Hi, I've checked out the cvs today, it compiles well with gcc 2.9.x but I can't compile it with gcc 3.1, this is my error output: Remove -I/usr/local/include from configure.in. You should not explicitly add system include dirs to the include search path (-I/usr/include or -I/usr/local/include). Hi, It works but I had to change configure directly because if I change configure.in I can't rebuild configure with autoconf, it exits with this error: configure.in:1237: error: AC_REQUIRE: cannot be used outside of an m4_defun'd macro configure.in:1237: AC_PROG_CPP is required by... configure.in:1237: the top level thanks, Fabio. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Can't compile with gcc 3.1- now works
On Mon, 3 Jun 2002, FAbel wrote: It works but I had to change configure directly because if I change configure.in I can't rebuild configure with autoconf, it exits with this error: configure.in:1237: error: AC_REQUIRE: cannot be used outside of an m4_defun'd macro /bin/sh ./developers/autogen.sh ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
Has anything happened with this bug? I was running developers/FullTest.sh on kaffe cvs/FreeBSD 4.3/gcc v2.95.3 and a similar thing was happening (e.g. StackDump seems to fail because it doesn't detect JNI exception handlers). tim stack I found one of the problems with Kaffe when compiling with -O4. Either the linker or the compiler is reordering the functions defined in jni.c. Normally this wouldn't matter, but Kaffe tries to identify if a program counter is in a JNI entry point method by testing to see if the PC is between Kaffe_JNI_estart and Kaffe_JNI_eend. Those two values are hardcoded to the first and last functions of interest defined in jni.c. When compiled with gcc -O4 (even with debugging and -g enabled, thank god), some of those methods are moved around. Specifically, the method used to invoke each new thread's run method uses Kaffe_CallVoidMethod, and on my machine the compiler moved that outside of the functions used to delimit the start and end of JNI-land. I hacked jni.c to iterate over all the pointers in the JNI entrypoint table and adjust the Kaffe_JNI_estart and Kaffe_JNI_eend until all of those methods were included. This fixed the particular test case (UncaughtException) but its exceedingly bogus because who knows what code was eventually included in this coverage. Unless someone knows of a good way of forcing a compiler/linker to keep a bunch of functions next to each other in the text segment, we'll need another approach. The best I could think of is to expand the current vmException buffer that's kept in each such method (they're chained and reachable off the thread object, see BEGIN_EXCEPTION_HANDLING in jni.c). If that struct could be expanded to include the address (and length!) of each the function its associated with, we could check the pc against that when looking for JNI exception handlers. Still for this approach to work, we'd need a way to get the size of a function's text out of the compiler... Anyone got other ideas? (Other than detecting and disabling -O4 in ./configure, of course...) -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] Not many people realize just how well known I am -- Anonymous ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] (Partial) success with RC1 under Linux/PPC
On Mon, 2002-06-03 at 14:08, Gwenole Beauchesne wrote: On 3 Jun 2002, Carlos Valiente wrote: Yep, intrp - the only one available for linux-ppc at the moment. Hadn't EGP wrote a JIT back-end? http://egp.free.fr/port-kaffe/port-kaffe-0.2.html Yes, he was in the process - in fact I helped him a little, since at the beginning he hadn even received his new iBook. I'm trying to carry on with the task of porting JIT to linux-ppc, but I'm having a tough time with ppc assembler. Anyone interested in sharing this sub-project, btw? ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Can't compile with gcc 3.1- now works
--- Gwenole Beauchesne [EMAIL PROTECTED] wrote: On Mon, 3 Jun 2002, FAbel wrote: It works but I had to change configure directly because if I change configure.in I can't rebuild configure with autoconf, it exits with this error: configure.in:1237: error: AC_REQUIRE: cannot be used outside of an m4_defun'd macro /bin/sh ./developers/autogen.sh works only if you have the proper versions of the tools installed. read FAQ/FAQ.automake for more information. It breaks quite nicely with current versions of auto* tools. A nice subproject for someone who knows enough about automake would be to update the correcponding files to work with current version of the tools. Any takers ? dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe 1.0.7 Release Candidate 1 available for download
Hi, I've made the 1.0.7-rc1 release available for download at: ftp://ftp.kaffe.org/pub/kaffe/testing/v1.0.x/kaffe-1.0.7-rc1.tar.gz http://www.kaffe.org/ftp/pub/kaffe/testing/v1.0.x/kaffe-1.0.7-rc1.tar.gz Please download it, compile it, and try it out. This is a test release of what will be 1.0.7. Well, i used the CVS version from this morning because of the debugexithook problem: uname -a FreeBSD irontown 4.3-RELEASE FreeBSD 4.3-RELEASE #3: Wed Jul 11 00:35:12 MDT 2001 gcc -v Using builtin specs. gcc version 2.95.3 [FreeBSD] 20010315 (release) Here's the output from developes/FullTest.sh: kaffe-jit3-debug: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-debug: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-optimized: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... Command FAILED: make -s -j 2 -C /z/stack/tmp6/krc1/kabuild/kaffe-jit3-optimized/ check tail -5 /z/stack/tmp6/krc1/kabuild/Trace-kaffe-jit3-optimized.txt == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 FAIL: StackDump.java FAIL: UncaughtException.java FAIL: finalexc.java FAIL: InvTarExcTest.java FAIL: CLTestConc.java FAIL: ExceptionTestClassLoader2.java FAIL: ExceptionInInitializerTest.java FAIL: ProcessClassTest.java FAIL: ProcessClassInst.java FAIL: ProcessClassStop.java FAIL: TestNative.java kaffe-intrp-optimized: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-stats: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-stats: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-default: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-default: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-debug-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-debug-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-optimized-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... Command FAILED: make -s -j 2 -C /z/stack/tmp6/krc1/kabuild/kaffe-jit3-optimized-static/ check tail -5 /z/stack/tmp6/krc1/kabuild/Trace-kaffe-jit3-optimized-static.txt == make[3]: *** [check-TESTS] Error 1 make[2]: *** [check-am] Error 2 make[1]: *** [check-recursive] Error 1 make: *** [check-recursive] Error 1 FAIL: StackDump.java FAIL: UncaughtException.java FAIL: finalexc.java FAIL: InvTarExcTest.java FAIL: CLTestConc.java FAIL: ExceptionTestClassLoader2.java FAIL: ExceptionInInitializerTest.java FAIL: ProcessClassTest.java FAIL: ProcessClassInst.java FAIL: ProcessClassStop.java FAIL: TestNative.java kaffe-intrp-optimized-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-stats-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-stats-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-jit3-default-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... kaffe-intrp-default-static: Cleaning ... Configuring ... Building ... Building Klasses ... Installing ... Checking ... So, the only failure have to do with the -O4 jni problem mentioned previously. Cheers, - Jim tim stack ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] make check results?
Hi alexander, --- Alexander Popov [EMAIL PROTECTED] wrote: Hi, I made the check on couple of different CVS version and the officially released 1.0.6 and all of them have most of the post-compilation tests FAIL. Try deleting your CLASSPATH before you run make check. export -n CLASSPATH on bash. cheers, dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
Hi Tim, --- Timothy Stack [EMAIL PROTECTED] wrote: Has anything happened with this bug? I was running developers/FullTest.sh on kaffe cvs/FreeBSD 4.3/gcc v2.95.3 and a similar thing was happening (e.g. StackDump seems to fail because it doesn't detect JNI exception handlers). I had a discussion about how to fix it with Pat, but no patch came out of it :( On the other hnad, that means that it's all still open for sugestions ;) dalibor topic __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
Has anything happened with this bug? I was running developers/FullTest.sh on kaffe cvs/FreeBSD 4.3/gcc v2.95.3 and a similar thing was happening (e.g. StackDump seems to fail because it doesn't detect JNI exception handlers). I had a discussion about how to fix it with Pat, but no patch came out of it :( On the other hnad, that means that it's all still open for sugestions ;) One idea I had was to have each JNI function in the BEGIN_EXCEPTION_HANDLING macro store its start and size in the 'vmException' buffer. The problem is there is no __builtin_function_size() GCC macro or anything that can tell you that. However, I know that there are tools that can generate such info from a .o file. So, we'd have to compile jni.c to jni.o, run a script over jni.o to extract the length of each function, create a .c file that defines 'size_function_name' for each JNI entrypoint, compile that and link it in. The hardest part will probably be getting the Makefiles to do that. :) I'll play around with this and see if it can be made to work (the stack unwinding code will have to be updated, too). -Pat - - --- --- -- -- - - - Pat Tullmann [EMAIL PROTECTED] I'd kill for a Nobel Peace Prize. -- S. Wright ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] -O4 jit3 problem
One idea I had was to have each JNI function in the
BEGIN_EXCEPTION_HANDLING macro store its start and size in the
'vmException' buffer. The problem is there is no
__builtin_function_size() GCC macro or anything that can tell you
that.
However, I know that there are tools that can generate such info from
a .o file.
So, we'd have to compile jni.c to jni.o, run a script over jni.o to
extract the length of each function, create a .c file that defines
'size_function_name' for each JNI entrypoint, compile that and link
it in.
The hardest part will probably be getting the Makefiles to do that. :)
I'll play around with this and see if it can be made to work (the
stack unwinding code will have to be updated, too).
What about using local labels in END_EXCEPTION_HANDLING?
#define BEGIN_EXCEPTION_HANDLING(X) \
vmException ebuf; \
ebuf.prev = (vmException*)unhand(getCurrentThread())-exceptPtr;\
ebuf.meth = (Method*)1; \
ebuf.start = jni_exception_start; \
ebuf.end = jni_exception_end; \
if (JTHREAD_SETJMP(ebuf.jbuf) != 0) { \
unhand(getCurrentThread())-exceptPtr = \
(struct Hkaffe_util_Ptr*)ebuf.prev; \
return X; \
} \
unhand(getCurrentThread())-exceptPtr = (structHkaffe_util_Ptr*)ebuf \
__label__ jni_exception_start;
#define END_EXCEPTION_HANDLING()\
__label__ jni_exception_end;\
unhand(getCurrentThread())-exceptPtr = (struct Hkaffe_util_Ptr*)ebuf.prev
This is based on:
http://gcc.gnu.org/onlinedocs/gcc/Local-Labels.html#Local%20Labels
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html#Labels%20as%20Values
-Pat
tim stack
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] SHA1PRNG fix
hi,
I attached a patch for SHA1PRNG.java, it still wasn't quite doing what it
was supposed to. Also, i think i forgot to mention that this was based on
Classpath's (broken) code, so the copyright should probably be gpl'ed.
thanks,
tim stack
Index: SHA1PRNG.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/SHA1PRNG.java,v
retrieving revision 1.3
diff -u -r1.3 SHA1PRNG.java
--- SHA1PRNG.java 12 May 2002 15:08:46 - 1.3
+++ SHA1PRNG.java 3 Jun 2002 20:36:08 -
-6,10 +6,6
*
* See the file license.terms for information on usage and redistribution
* of this file.
- *
- * NB THIS DOES NOT ACTUALLY IMPLEMENT SHA1PRNG - it uses random and
- *is a place holder.
- *
*/
package kaffe.security.provider;
-25,14 +21,15
public class SHA1PRNG
extends SecureRandomSpi
{
- private static final int SEED_SIZE = 20;
- private static final int DATA_SIZE = 40;
+ private static final int SEED_SIZE = 8;
+ private static final int DATA_SIZE = 16;
private MessageDigest md;
private byte seed[] = new byte[SEED_SIZE];
private int seedPos = 0;
private byte data[] = new byte[DATA_SIZE];
private int dataPos = 0;
+ private long counter = 0;
public SHA1PRNG()
{
-43,7 +40,7
this.md = MessageDigest.getInstance(SHA-1);
new Random().nextBytes(this.seed);
- digest = this.md.digest(this.data);
+ digest = this.md.digest(this.seed);
System.arraycopy(digest, 0, this.data, 0, SEED_SIZE);
}
catch(NoSuchAlgorithmException e)
-77,7 +74,8
protected void engineNextBytes(byte[] bytes)
{
- if( bytes.length (20 - this.dataPos) )
+ this.counter += 1;
+ if( bytes.length (SEED_SIZE - this.dataPos) )
{
System.arraycopy(this.data, this.dataPos,
bytes, 0,
-112,6 +110,22
this.data,
SEED_SIZE,
SEED_SIZE);
+ this.data[SEED_SIZE] =
+ (byte)(this.counter);
+ this.data[SEED_SIZE + 1] =
+ (byte)(this.counter 8);
+ this.data[SEED_SIZE + 2] =
+ (byte)(this.counter 16);
+ this.data[SEED_SIZE + 3] =
+ (byte)(this.counter 24);
+ this.data[SEED_SIZE + 4] =
+ (byte)(this.counter 32);
+ this.data[SEED_SIZE + 5] =
+ (byte)(this.counter 40);
+ this.data[SEED_SIZE + 6] =
+ (byte)(this.counter 48);
+ this.data[SEED_SIZE + 7] =
+ (byte)(this.counter 56);
digest = this.md.digest(this.data);
System.arraycopy(digest,
0,
Re: [kaffe] SHA1PRNG fix
bah, i forgot a couple of other security fixes:
Change name of SHA - SHA-1
Add aliases to the Kaffe provider
tim stack
Index: SHA.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/SHA.java,v
retrieving revision 1.2
diff -u -r1.2 SHA.java
--- SHA.java22 Nov 2001 06:21:25 - 1.2
+++ SHA.java3 Jun 2002 20:57:57 -
-17,7 +17,7
public final class SHA extends UpdateDigest {
- public static final String DIGEST_NAME = SHA;
+ public static final String DIGEST_NAME = SHA-1;
public static final int DIGEST_LENGTH = 20;
public SHA() {
Index: Kaffe.java
===
RCS file: /cvs/kaffe/kaffe/libraries/javalib/kaffe/security/provider/Kaffe.java,v
retrieving revision 1.3
diff -u -r1.3 Kaffe.java
--- Kaffe.java 4 Jan 2002 05:12:33 - 1.3
+++ Kaffe.java 3 Jun 2002 20:57:57 -
-39,8 +39,12
kaffe.security.provider.MD4);
put(MessageDigest.MD5,
kaffe.security.provider.MD5);
- put(MessageDigest.SHA,
+ put(MessageDigest.SHA-1,
kaffe.security.provider.SHA);
+ put(Alg.Alias.MessageDigest.SHA1,
+ SHA-1);
+ put(Alg.Alias.MessageDigest.SHA,
+ SHA-1);
put(SecureRandom.SHA1PRNG,
kaffe.security.provider.SHA1PRNG);
return null;
[kaffe] Please remove me from the list.
Hi Admin, Please remove me from the list.I could not remove myself from the list. Uday ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] problem about Kaffe run twice in one process
Hi, I want to run kaffe in my program in linux. I'd like to start kaffe as a thread in a process. After kaffe finishes, it will be requested to restart as a thread in the same process. However, the second time I run kaffe, it does not work. It seems kaffe is designed to run once and then exit to the system. I make some modification. It works when running single thread of Java Application. But multithreads Java Application stops in the second round of running. What i do is like this:configured kaffe --with-threads=unix-pthreads. Turn off two or three assertion in JNI_CreateJavaVM(). Set hashTable=0 and tLock=0. in the initialization Is there anyone try this? Any advice is welcome. Thanks in advance. BR, Qiujing
Re: [kaffe] -O4 jit3 problem
I wrote:
Tim wrote:
What about using local labels in END_EXCEPTION_HANDLING?
Ah! That's probably exactly what is needed. I was hoping there was
some GCC way of handling this.
Seems to work, too!
The attached patch lets optimized versions of Kaffe pass all(*) the
built-in regression tests. In fact, it should improve odd corner
cases a bit, as now Kaffe_JNI exception handlers cover only the code
they should.
(*) InternHog seems to fail in the (non-optimized) interp-debug builds
now. Of course, I can't get it to fail when run under GDB... Bah!
I'll keep poking at that one.
In figuring out how the vmException code was used, I discovered that
half of the fields were only used in the interpreter, and half only
used in the Kaffe_JNI entrypoints, so I updated the struct to use a
union (saves 8 bytes per vmException! :). I also renamed
'vmException' to 'VmExceptHandler' and hid the accesses to the struct
behind inline functions (mostly to get a lot of asserts in).
I'm not entirely confident in this change, because I haven't looked to
see which tests (if any) actually stress this code. I'll look more
closely at this, too.
Anyway, if anyone has comments on the patch let me know. JIM, let me
know if you think this is safe to check in, and I will...
-Pat
- - --- --- -- -- - - -
Pat Tullmann [EMAIL PROTECTED]
Ignorance more frequently begets confidence than does knowledge.
diff -u -r -N --exclude=CVS --exclude=.* --exclude=DEAD --exclude=Makefile.in
--exclude=configure pure/kaffe/kaffevm/classMethod.c optjit/kaffe/kaffevm/classMethod.c
--- pure/kaffe/kaffevm/classMethod.cThu May 30 12:06:19 2002
+++ optjit/kaffe/kaffevm/classMethod.c Mon Jun 3 20:25:58 2002
@@ -1559,6 +1559,7 @@
return true;
}
+#if defined(TRANSLATOR)
/*
* When do we need a trampoline?
*
@@ -1604,6 +1605,9 @@
}
return (false);
}
+#endif /* TRANSLATOR */
+
+
/*
* Build a trampoline if necessary, return the address of the native code
diff -u -r -N --exclude=CVS --exclude=.* --exclude=DEAD --exclude=Makefile.in
--exclude=configure pure/kaffe/kaffevm/exception.c optjit/kaffe/kaffevm/exception.c
--- pure/kaffe/kaffevm/exception.c Thu May 30 12:06:19 2002
+++ optjit/kaffe/kaffevm/exception.cMon Jun 3 22:57:20 2002
@@ -37,6 +37,7 @@
#include machine.h
#include slots.h
#include gcj/gcj.h
+#include kaffe_jni.h
#if defined(INTERPRETER)
#defineFIRSTFRAME(f, e)/* Does nothing */
@@ -48,8 +49,6 @@
static void floatingException(struct _exceptionFrame *);
static void dispatchException(Hjava_lang_Throwable*, stackTraceInfo*) __NORETURN__;
-extern void Kaffe_JNIExceptionHandler(void);
-
extern void printStackTrace(struct Hjava_lang_Throwable*, struct Hjava_lang_Object*,
int);
static bool findExceptionBlockInMethod(uintp, Hjava_lang_Class*, Method*,
exceptionInfo*);
@@ -297,9 +296,9 @@
return (0);
}
#endif
-#else
-vmException* nfm;
-nfm = ((vmException*)fm)-prev;
+#else /* INTERPRETER */
+VmExceptHandler* nfm;
+nfm = ((VmExceptHandler*)fm)-prev;
return (nfm);
#endif
}
@@ -330,8 +329,22 @@
meth = findExceptionInMethod(frame-pc, class, einfo);
- if (einfo.method == 0 IS_IN_JNI_RANGE(frame-pc)) {
- Kaffe_JNIExceptionHandler();
+ assert(meth == einfo.method);
+
+ /*
+* If no exception block found in method, perhaps
+* it is a Kaffe_JNI entrypoint?
+*/
+ if (einfo.method == 0)
+ {
+ VmExceptHandler* ebuf =
+(VmExceptHandler*)(unhand(getCurrentThread())-exceptPtr);
+ if ((ebuf != 0)
+vmExcept_isJNIFrame(ebuf)
+vmExcept_JNIContains(ebuf, frame-pc))
+ {
+ /* Does not return. */
+ Kaffe_JNIExceptionHandler(ebuf);
+ }
}
/* Find the sync. object */
@@ -404,18 +417,21 @@
{
Hjava_lang_Object* obj;
exceptionInfo einfo;
- vmException* frame;
+ VmExceptHandler* frame;
bool res;
- for (frame = (vmException*)unhand(ct)-exceptPtr; frame != 0; frame =
frame-prev) {
+ for (frame = (VmExceptHandler*)unhand(ct)-exceptPtr; frame != 0;
+frame = frame-prev) {
- if (frame-meth == (Method*)1) {
+ if (vmExcept_isJNIFrame(frame)) {
unhand(ct)-exceptPtr = (struct Hkaffe_util_Ptr*)frame;
- Kaffe_JNIExceptionHandler();
+ Kaffe_JNIExceptionHandler(frame); /* No Return */
}
/* Look for handler */
- res = findExceptionBlockInMethod(frame-pc,
eobj-base.dtable-class, frame-meth,
