[kaffe] x86 trampoline brokenness and classloader problem

[Timothy Stack]

hi,

There seems to be a bug with the current implementation of 
i386_do_fixup_trampoline that masks the calling stack frame from stack 
traces.  Unfortunately, this presents a problem for any code that tries 
to catch an exception generated by the jitter (which is rare atm).  The 
problem is that the return pc associated with the stack frame belongs to 
i386_do_fixup_trampoline and not the original method.  So, when the 
exception code is walking the stack it will see, and ignore, a native 
function (i386_do_fixup_trampoline) while continuing up the stack.  So, 
I propose the following modification, we first pop the trampoline return 
address off the stack, create a real frame for 
i386_do_fixup_trampoline,  and then push the return address back on for 
soft_fixup_trampoline.  It seems to work for me:

asm(
         START_ASM_FUNC() C_FUNC_NAME(i386_do_fixup_trampoline) "\n"
C_FUNC_NAME(i386_do_fixup_trampoline) ":                        \n
         popl    %eax                                            \n
         push    %ebp                                            \n
         mov     %esp,%ebp                                       \n
         push    %eax                                            \n
         call    " C_FUNC_NAME(soft_fixup_trampoline) "          \n
         popl    %ecx                                            \n
         leave                                                   \n
         jmp     *%eax"
         END_ASM_FUNC()
);


Now, onto the problem that exposed the above problem...  The exception 
handling code in classMethod.c:loadClass() doesn't appear to do the 
right thing, if a user ClassLoader throws a ClassNotFoundException, it 
will just pass this up to the caller.  Shouldn't this be converting the 
ClassNotFound to a NoClassDefFoundError and marking the errorInfo.type 
with KERR_NO_CLASS_FOUND?  Otherwise, the verifier will fail too quickly 
and the jitter will throw a ClassNotFoundException, which is neither a 
RuntimeException or Error and shouldn't be thrown willy nilly.

thanks,

tim stack