Alpha (Re: [kaffe] Testing for 1.1.0 release)

[mcmahill@mtl.mit.edu]

On Wed, 21 May 2003, Dalibor Topic wrote:

> Hi Dan,
> 
> --- mcmahill@mtl.mit.edu wrote:
> 
> > I only fail 3 of 133 now on my alpha (NetBSD-1.6.1)
> 
> Cool, then here's the next challenge: run the developers/FullTest.sh script on
> you platform and report the results back. You'll have to adapt the script's
> paths. Suggested format is 
> 

work underway now...

> > test/regression/InetSocketAddressTest.fail
> 
> how does this one fail, i.e. could you take a look at InetSocketAddressTest.out
> and InetSocketAddressTest.fail, and check what's the problem?

 % cat test/regression/InetSocketAddressTest.out
java.lang.IllegalArgumentException: Null host name value
java.lang.IllegalArgumentException: Bad port number: 100000
java.lang.IllegalArgumentException: Bad port number: 65536
java.lang.IllegalArgumentException: Bad port number: -1
java.lang.IllegalArgumentException: Bad port number: -128
Unresolved bad.bad.bad: true
Unresolved toString(): bad.bad.bad:0
Unresolved localhost: false
Resolved toString(): localhost/127.0.0.1:0
Wildcard address: true
Port: 128
Null address is wildcard: true


> > but I suspect there was an underlying bug with an unitialized value in
> > addition to needing IEEE support.
> 
> If you can figure out what it is, I'd welcome a patch. We don't have any active
> Alpha hackers working on kaffe at the moment, so any help on that platform is
> most welcome.

this could easily be a machine independent buglet which only happens to
show up on alpha with a SIGFPE but could show up in subtle ways or not at
all on other systems (including alpha with -mieee).  I looked a little,
but didn't see anything.


> kaffe generates on alpha-netbsd and see what gcc is complaining about.

I've fixed most of them.  The huge number generated by kaffe.def is
because the program counter ends up being a long int which is 64 bits on
alpha while the dprintf's between lines 53-60 of 
kaffe/kaffevm/intrp/machine.c use %d for the format string.  %d is an
integer which is 32 bits.  On something like i386, sizeof(long) ==
sizeof(int) == 32 so there's no problem.

By changing to %ld, my warnings went away.  You may want to also cast to a
long too.  Ie, dprintf("pc=%ld", (long) pc).

in kaffe/kaffeh/support.c, these warnings may be a bit worse:

support.c:422: warning: cast to pointer from integer of different size
support.c:423: warning: cast to pointer from integer of different size

f->name = (void*)((u4)name_index);

u4 is a uint32 (32 bit integer).  Then you're casting to a pointer which
is 64 bits.  But then again name_index starts out as a u2 (16 bit
number?) so maybe you don't care about the top 48 bits...

support.c:504: warning: cast from pointer to integer of different size
support.c:505: warning: cast from pointer to integer of different size
name_index = (u2)(u4)(f->name);

same thing in reverse.


I'll attach patches after running another 'make check' with these format
string fixes.

-Dan