[Sablevm-user] FreeBSD port of SableVM

[Archie C. <ar...@de...>]

Hi,

I'm new to this list... doesn't seem like there's much going on though.

I've been wanting to play with SableVM a little bit, and the first
step in doing that of course is getting it to work on FreeBSD :-)
So I've added FreeBSD ports for sablevm-0.1.6 and sablepath-0.1.3.

Doing this has required some patches to fix some Linux-centric assumptions.
I thought it might be useful to summarize these here. Just a few patches
were necessary, so in general portability is not far away if the SableVM
developers are interested. FYI the patches are visible here:

    http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablepath/files/
    http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/sablevm/files/

I tried half-heartedly to make these patches portable (rather than
simply breaking Linux compatbility in favor of FreeBSD), so some
of those changes are candidates for mergeing into the source while
others aren't.

The changes required were:

- FreeBSD needs these additional CFLAGS:

    -pthread
	Link with the reentrant version of libc (libc_r).
	This flag replaces the "-lpthread" flag on Linux.

    -I/usr/local/include -L/usr/local/lib
	FreeBSD does not automatically search /usr/local for
	include files and libraries when compiling and linking.

    -D_P1003_1B_VISIBLE
	Required when compiling sablevm to have 'siginfo_t' defined
	when including <signal.h>.

- FreeBSD does not have a libdl; dlopen() et.al. are part of libc.

- FreeBSD does not have a "malloc.h"; malloc() is declared in <stdlib.h>.

- FreeBSD has <machine/endian.h> instead of <endian.h> and the
  macro to use is BYTE_ORDER rather than WORDS_BIGENDIAN

Finally, I found what appears to be a bug or at least inconsistency
between Linux and FreeBSD.  When running HelloWorld, the first
SIGSEGV comes from the first call to _svmf_interpreter(), at line 97,
because 'frame' is NULL:

 88 {
 89   /* This causes a sigfault for _svmv_instructions initialization, as
 90      env->stack.frame->method is NULL at that point.
 91      This way, we do not introduce overhead to normal _svmf_interpreter
 92      execution path. */
 93
 94   _svmt_stack_frame *frame = env->stack.current_frame;
 95   _svmt_method_info *method = frame->method;
 96
 97   locals = (_svmt_stack_value *) (((char *) frame) - method->locals_size);
 98   stack = (_svmt_stack_value *) (((char *) frame) + method->stack_offset);
 99
100   /*    printf ("- %s.%s %s\n",
101      method->class_info->name,
102      DREF (method->name, value),
103      DREF (method->descriptor, value)); */
104 }

When the signal is handled however, info->si_addr is 0x3c (presumably
because the 'locals_size' field of 'method' has that offset). This
causes the (commented out) code below to be executed, leading to an
abort(). When this patch is added however HelloWorld works:

--- sablevm-0.1.6.orig/src/libsablevm/error.c	Sun Apr 15 03:52:45 2001
+++ sablevm-0.1.6/src/libsablevm/error.c	Tue Jul  9 13:11:04 2002
@@ -202,11 +202,13 @@
       {
 	/* probably NULL pointer exception.  Let's check... */
 
+#if 0
 	if (info->si_addr != NULL)
 	  {
 	    /* not a NULL memory access. We don't handle this. */
 	    goto delegate_0;
 	  }
+#endif
 
 	signal_throw (NULL_POINTER_EXCEPTION);
       }

I don't understand how this can work under Linux unless info->si_addr
is always NULL, which would seem like a Linux bug.

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com