Kaffe bug on PC

Michael Gesundheit mikeg at rocketmail.com
Wed Oct 29 18:06:52 PST 1997






---"John D. Gwinner" <gwinner at northnet.org> wrote:
>
> Michael:
> ..
> > it has to do with the difference between the
compilers
> > and the way they handle unions. The size of the
slots
> > union is 8 bytes. I see the pointer in the upper 4
> > bytes in both the PC and Solaris. gcc takes the
pointer
> > correctly. VC++ takes the lower 4 bytes which are
NULL.
> > I'll address this problem today and broadcast the
fix.
> > It smell like a fundamental issue for PC.
> 
> Just to cover all bases, have you examined the
packing (#pragma pack)? 

No, under 0.9.2 the thread package does not require
assembly. setjmp/longjmp is used.
 I
> don't think there is a guaranteed byte placement
within a union, but I
> could be wrong -- I'm just guessing.
> 
> Are you using INT64 for the 8 byte quantity to
break out the 4 bytes? 

Yes.

> That might be one way to go.

The problem as I see it at this point is not a union
issue. I realized today that the problem comes from
the initial GETSTATIC opcode processing. The
move_ref_const macro moves the pointer
field->info.addr to tmp which is a slots pointer then
the macro load_ref move the contant, which is 0 (!!) to
the stack. Later on the bytecode INVOKEVIRTUAL takes
this stack entry as a pointer and crashes. At this 
point I think the bug is in initializing my 
HelloWorldApp class. This missing pointer should be 
set when the class is loaded and processed. I hope
that the Solaris I have next to the PC will help
tracing the class initialization.

--Michael
macro moves a field->info.addr pointer which points
to 0. The following move_ref_const

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



More information about the kaffe mailing list