Alpha (Re: [kaffe] Testing for 1.1.0 release)
mcmahill at mtl.mit.edu
mcmahill at mtl.mit.edu
Thu May 22 04:44:01 PDT 2003
On Wed, 21 May 2003, Dalibor Topic wrote:
> Hi Dan,
>
> --- mcmahill at 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
More information about the kaffe
mailing list