Menu
▾
▴
[rvm-research] building Jikes at OS X 10.5 (Leopard) PPC/IA-32
|
From: Kenneth H. <ken...@ug...> - 2008-08-27 09:04:48
|
Hello,
While setting up our research environment using Jikes, we noticed that
Jikes (SVN head) doesn't build on OS X 10.5 (Leopard) out of the box,
neither on PowerPC (my PowerBook G4), nor on IA-32 (my iMac, and
Andy's MacBook Pro).
I've come up with some patches to resolve these issues, with varying
success. The PowerPC issues have been resolved, and the build has been
thoroughly tested (using DaCapo and SPECjvm98) and found to be working
correctly (imho). The IA-32 build issues are also resolved, but I'm
still running into runtime issues (none of the DaCapo benchmarks run,
and they all seem to results in the same problem).
I should add that I was only able to test my patches on a Leopard
system, I don't have access to any Tiger (OS X 10.4) setups anymore...
I tried to be careful about not breaking stuff that worked before, but
I have no way of testing this. I hope someone else is willing to
confirm the correctness of my patches on a Tiger setup (both on PPC
and IA-32).
Before I go on to describe the patches I've come up with: I was quite
surprised that Jikes didn't build correctly on the IA-32 system
running OS X 10.5. Is nobody else using Jikes on this type of system?
The PowerPC issue is probably less surprising, because Macs running on
PowerPC are probably dying out pretty quickly...
The patch for the PowerPC system (SVN diff is attached) consists of
three major fixes:
1) fixing the prefix issues ("__") which seem to occur in Leopard;
this was already fixed in the IA-32 related source code, but wasn't
ported to the PPC version. It mainly consisted of using the
appropriate macros (DARWIN_PREFIX, _STRUCT_UCONTEXT) in the lines of
code that needed fixing.
2) the sigreturn system call that is used a few times, seems to have
disappeared in Leopard; I was unable to find any documentation on how
to fix this, but just removing the sigreturn calls (and assuming the
return calls following them clean up the stack) seems to be working...
3) fixing sigaltstack related issues and avoiding redefinition of NULL
The patch for the IA-32 system is simpler, but also more confusing...
One of the macros (IA32_STMM) was relying on the fact that the value
of the 'run' variable could be used to select the appropriate struct
elements. Although this works on most systems (where the struct
element is an array), the macro definition that is used on Leopard/
IA-32 doesn't work, because the struct elements need to be determined
statically (separate struct element instead of one array). Hence,
unrolling the small for loop that used the IA32_STMM macro solves the
issue, allowing the macro to select the correct struct elements. It's
probably not the most elegant fix, but it was the best I could come up
with.
Although this fixes the build problem, still some runtime issues
remain. I'm seeing the error message below when running any of the
DaCapo benchmarks. I don't see how this could be related to my patch
(the unrolled version is equivalent to the for loop version in my
opinion), so I'm guessing there's another open issue here...
Any guidelines on how to dig deeper into this issue are appreciated.
JikesRVM: internal error
JikesRVM: WHOOPS. Got a signal (Bus error; #10) that the hardware
signal handler wasn't prepared for.
JikesRVM: UNRECOVERABLE trapped signal 10 (Bus error)
handler stack 0x00069c88
gs 0x00000037
fs 0x00000000
es 0x0000001f
ds 0x0000001f
edi 0x00000000
esi -- PR/VP 0x32607434
ebp 0x310822e4
esp -- SP 0x3108209c
ebx 0x00000001
edx 0x00000001
ecx 0xfffffc48
eax 0x310820f0
ss 0x0000001f
eip 0x35c12173
cs 0x00000017
trapno 0x0000000e
err 0x00000004
eflags 0x00010202
fpstate 0xffffffff
oldmask 0xffffffff
cr2 0x00000000
fp0 0x0e0aff130e0aff13ffff
fp1 0x000a000e001300ffffff
fp2 0x0004000000000000ffff
fp3 0x00010004000800ffffff
fp4 0x0000000000008000bfff
fp5 0x00009a403570973c4028
fp6 0x00000000000083404009
fp7 0x00000000000083404009
greetings,
Kenneth
|