[kaffe] broken build for arm + bug

[ferenc.dosa@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