[Sablevm-developer] Quick message...

[Etienne M. G. <eti...@uq...>]

Hi all!

I'm taking a couple of minutes (my break of the day), to write a few
words.

---

I've release 1.0.3.  The main difference is that I fixed a configure
bug.  My test for detecting i*86-*-gnu was flawed and always failed.
This means that on x86/GNU-Linux, the slower direct-threaded engine
was selected for the default build.  I added the missing configure
macro call.

Note to porters: If you are porting to a system with a unified
dat/instruction cache (x86 based, for example), you'll want to use the
inline-threaded engine.  Search for i*86-*-gnu in configure.ac and add
your architecture to the test.

---

First, a general note.  In order to test SableVM on a new platform,
and to be able to trace easily though it using a debugger like gdb, or
better DDD (Data Display Debugger, a wonderful gdb X based front-end),
you sould use the --enable-debugging-features.  If you do not want all
the assertion stuff (which is a good idea to keep around in the
beginning), you can use --with=threading=switch.  You can get both
versions living together (and more) using the build-many script.

In simpler terms:

$ ./build-many /home/myself/sablevm-binary

Then, you simply debug the "sablevm-debug" binary, which automatically
links with a "gcc -O0" version of the native library.

Of course, you can simply look inside the build-many script, and
extract the commands to build only the components you need.

Do not try to debug using the inline-threaded engine; you won't be
able to step through most bytecode instructions (as they'll be
inlined).

---

It is important to test code ported to new platform with a version of
sablevm that DO NOT use signals for detecting exceptions.  The
"sablevm-debug" and "sablevm-nosig" both qualify for such tests.  This
is because signals might wronfully catch an otherwize erroneous
condition (e.g. segfault) and transform it into a
NullPointerException.  In some cases, the application will catch the
(erroneous) exception and then have an unexpected behavior.

This might well explain the failure on powerpc...

---
To Mark Wielaard,

I've quickly looked at your CAS (comp. and sw.) implementation.  I do
not know powerpc assembly, but your code seems relatively ok at fist
sight.

--

To Archie Cobbs

I've compiled the DoublePrint class, and ran it with sablevm (1.0.3)
without any problem.  It prints "HelloWorld".  Try the sablevm-debug
version.  (I've attached the .class file i've compiled [I had lost
yours]).

In case you wanted to see a trace of ALL exceptions thrown inluding
ones that ARE catched (except class loading related ones, which are
usually normal due to class loader delegation), replace the "#ifdef
COMMENT" at the beginning of the exception handling code in
src/libsablevm/interpreter.c by "#ifndef COMMENT".  Do not forget to
revert the code once you're done debugging.

---

That's all for today.

Have fun!

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/