Tim wrote:
I had a little problem
...
in exception.h. The assert(start end); needs to be changed to
assert(start = end); otherwise it will fail if there are no
instructions between the start_label and end_label. Which seems to
happen with Kaffe_ExceptionOccurred() and if
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!
I had a little problem with:
static inline void
I wrote:
(*) 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.
This is very bizarre.
As far as I can tell, it only happens in interp+debug (static or not),
with the patch I just
On Tue, 4 Jun 2002, Patrick Tullmann wrote:
- * XXX variable declarations in macros are nasty.
+ * Each BEGIN_EXCEPTION_HANDLING macro must be matched by an
+ * END_EXCEPTION_HANDLING macro call in the same scope. Each should
+ * be used only once in a given JNI entrypoint.
+ *
+ * Yes,
Gwenole wrote:
On Tue, 4 Jun 2002, Patrick Tullmann wrote:
- * XXX variable declarations in macros are nasty.
+ * Each BEGIN_EXCEPTION_HANDLING macro must be matched by an
+ * END_EXCEPTION_HANDLING macro call in the same scope. Each should
+ * be used only once in a given JNI
I wrote:
(*) 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.
This is very bizarre.
i can replicate it here.
Kaffe seg-faults in string.c:stringCompare, when its passed
Not sure if the fix is valid. If they can be freed before the string,
then you'd have to avoid dereferencing all interned strings here...
fyi, I hacked hashtab.c to avoid the deep comparison when removing a
value. Now, it will just check the pointers and fail instead of also
trying the
Patrick Tullmann writes:
Yes. The string isn't walked anymore by the time it's destroyed,
the char array could already be gone.
Ah, okay. I'm also amazed that this hasn't cropped up before, and
still refuses to crop up with the other builds of Kaffe... Very odd.
Anyone want to come
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
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
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
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
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
13 matches
Mail list logo
