[kaffe] -O4 jit3 problem

Timothy Stack stack@cs.utah.edu
Mon, 3 Jun 2002 09:28:30 -0600 (MDT)


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                                       tullmann@cs.utah.edu
>     Not many people realize just how well known I am -- Anonymous
> 
> _______________________________________________
> kaffe mailing list
> kaffe@kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
>