Simon Marlow wrote:
I'd put money on it being due to this in configure.ac:
tr -d '\r'
Thanks, I installed a fresh copy of GNU coreutils which fixed it.
I'm still trying to get the head working on sparc/solaris again though,
it seems the new "foreign import prim" support doesn't know about sparc
register windows.
A disassembly of
libraries/integer-gmp/dist-install/build/cbits/gmp-wrappers.o says:
00000000 <integer_cmm_int2Integerzh>:
0: 9d e3 bf 90 save %sp, -112, %sp -- push register window
4: a0 10 00 11 mov %l1, %l0 -- try to store R1 to %l0
8: 84 06 e0 0c add %i3, 0xc, %g2 -- try to add 0xc to Hp
c: c2 06 60 5c ld [ %i1 + 0x5c ], %g1 -- try to load HpLim
into %g1
10: 80 a0 80 01 cmp %g2, %g1 -- compare Hp+0xc with HpLim
This function is being imported with:
foreign import prim "integer_cmm_int2Integerzh" int2Integer#
:: Int# -> (# Int#, ByteArray# #)
However, it's being called with:
0x0034af10 <sOs_info+172>: st %g1, [ %i0 + -4 ]
0x0034af14 <sOs_info+176>: add %i0, -4, %i0
0x0034af18 <sOs_info+180>: call 0x344cb0 <integer_cmm_int2Integerzh>
0x0034af1c <sOs_info+184>: add %i3, -8, %i3
The problem is that the "save" instruction at the start of
integer_cmm_integer2Intzh pushes the SPARC register window down.
Before the save, register %i1 (the BaseReg) contains a pointer to the
STG register table, and %o1 contains the junk value 0x28. After the
save, %i1 now contains 0x28, so the ld [ %i1 + 0x5c ], %g1
instruction fails.
What calling convention do we want for "foreign import prim" on sparc,
considering primops have to access the STG regs? I suppose we could copy
all the STG regs stored in %i0-%i5 to %o0-%i5 before the save. Or maybe
it'd be better make the cmm primop do the copy if it needs to push the
register window?
Thanks,
Ben.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
