[kaffe] broken build for arm + bug

[ferenc.dosa at nokia.com]

Hi guys,

great work you are doing there, congratulations for the frequent releases. Also, the doc on cross compilation helped me a lot. My contribution would be this report :-)

I downloaded the kaffe-1.1.1.tar.gz, and try to crosscompile it for arm-linux (with unix-pthreads). Kaffe-1.1.0 seemed to be broken with respect to loading/displaying images for both i386-linux and arm-linux.


1) broken exception.c

At exception.c:366 there is a usage of macro FRAMEOBJECT, which, in turn, is substituted with the definition found under config/arm/jit.h. By looking at kaffe-1.1.0 sources, it expects 'struct _exceptionInfo' coming as 3rd macro arg. However, at the named place it is something else there (I noticed the old usage was correct in unwindStackFrame(), a nonexistent function in 1.1.1, where actually there is an assertion claiming an identity of some method found in the frame and in the exceptionInfo).

According to what I've found, this FRAMEOBJECT is used only in exception.c, and only at the line 366. For the time being I just modify the definition in config/arm/jit.h to expect 'struct _methods' instead of exceptionInfo...


2) broken jni.c

At jni.c:3894, there is a use of macro 'slot_freetmp', that did not exist in kaffe-1.1.0. While I have absolutely no idea why it _did_ compile for the i386, it breaks down for the arm because it does not know NOREG, which presumably comes from jit/registers.h.

For now, I #include "registers.h" right after the "slots.h".


3) bug: displaying images

Compiled with the changes above, it passes the smoke tests, except it still does not show the images on the arm (it does show it on pc, though).


4) "feature": native I/O operations interrupted

The reason I need kaffe with unix-pthreads is that I do my own socket operations in C (which I interface from Java code via JNI calls). What I noticed is that in certain situations (on the pc), all I/O operations (like accept()) are interrupted in _all_ native threads. I assume it's one of the signal the VM uses. While the I/O wrappings take care of interrupted I/O calls for the VM, they do not know about my native sockets, of course. Testing it with another VM, this does not happen. I wonder if it would be possible to prevent I/O calls in all threads being interrupted... :-)


Thanks a lot for any help.

Br,
Ferenc Dosa Racz