[FIXED] Seeking debug tips for Kaffe on NSPR

[Robert S. Thau]

Robert S. Thau writes:
 > In particular, javac run on the port always fails --- within the
 > java.util.zip code, findEND throws a ZipException saying "not a zip
 > file (END header not found)", following which the compiler itself very
 > shortly reports that it can't find java.lang.Object.  (This is, of
 > course, with a classpath and other environment variables on which
 > jthreads Kaffe runs javac perfectly).

FYI, I found the problem --- fstat is omitted from the
Kaffe_SystemCallInterface. 

There are two places in the code which call fstat --- one in
findInJar.c, which does not go through the syscall dispatch table (as
I noted --- perhaps this should be fixed), and one in the native
methods for RandomAccessFile.  The latter code does otherwise go
through the syscall interface, which means that it is trying to do a
native fstat on my shadow file descriptors, with unhappy results.

For the moment, I've kludged around the problem, but in the long run,
it would probably best to add fstat to the tables.  (There are other
cases where additional entries might be useful --- in particular,
entries in the GC table for walkConservative and markObject, so that
the stack-walking code doesn't need to call them directly, by name;
something that would be called when an iLock is destroyed, so that the
lock package can free its own data structures; and possibly init
entries which would be invoked before anything else, to avoid the
somewhat tedious business of checking "initialized-yet" flags.  The
lock business, in particular, is presently a pretty serious memory
leak in my port).

On to figure out why the GC torture test exits without producing any
output at all... (yes, yes, you start by uncommenting some of the
print statements; however, given the nature of the thing, I have an
unnatural fear that simply turning one of those on will eliminate a
Heisenbug...). 

rst