Fwd: Kaffe runs(!) under VC++

[Michael Gesundheit]

Sorry, my mailer under MS Explorer just sent my mail
after I hit TAB. 

Here it is again:

I just got kaffe to spit HelloWorld! for the first
time under VC++ 5.0. I would not call it running yet
before it will pass the entire test package but this is
a start and more important if anybody out there would
like to help it will be great.
 
The main bug was, and here I'm looking for
explanation help, the following:

First, the bug manifest itself deep down in Java code
when trying to do the print of HelloWorld the VM
crashed. It crashed when Java stack slot had a field
pointer to the "out" field of the FileDescriptor
class which was 0. Why? here is the bug:

javah uses a stack_item union to pass parameters in
the stubs it generates. The union:
 
typedef union {
     jint      i;
     jlong     l;
     jfloat    f;
     jdouble   d;
     jref      p;
}stack_item;

In System.c where the some of the stubs are you can
find:
java_lang_System_setOut0(_P_[0].p){}

This is an attempt to pass a jref (void *) as a
parameter. The value which was passed is 0 even though
the pointer is there !!. 

I don't have a clear explanation but I know the 
following:

I added a local

void *vp = _P_[0].p;

and passed vp as a parameter. This works fine. Now the
parameter is passed as expected.
I did the same to all the functions in this file and
kaffe runs!!

I did expirimented a little with union on Solaris and
PC and found the following:

In PC when I write to any of the union elements the
value appears in all of them in the least significant
4 bytes. (I wrote a pointer).
On a sparc system if I wrote to a long long the value
appear in the UPPER 4 bytes!!. All the union elements
which were no longer then 4 bytes showed 0 (ZERO)!!!
If I wrote to a 4 bytes element then all the elements
showed the value.

Now, remember that Java code has no connection to the 
C compiler which compile the C code. If Java puts the 
value in the upper part of the 8 bytes then, VC++
at least does not find it. It takes the value in the 
lower 4 bytes.
This does not explain how is the GNU compiler find the
correct value on Solaris. Whats interesting is that on 
Solaris if I wrote to the long long and then moved it 
to a void * the data was fine. But so is VC++. It 
must be different when the value is put on the stack
as a passed parameter. I can see it happend. The 
compiler gets a byte location, like _P_[0].p in our
case and takes 4 bytes as the function prototype
indicates (void *).

If you have a better explanation I'll be happy to hear.

--Michael

_____________________________________________________________________
Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com