------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1430
--- Comment #14 from Zoltan Herczeg <hzmester@???> 2014-01-15 20:35:01 ---
This is getting more and more confusing. The wrong endianness detection is ok,
since it detects these settings from compiler defines, and there is no check
for PPC-LE.
But these zeroes are obviously wrong:
0x00003fffb7dfe2a8: .long 0x0
0x00003fffb7dfe2ac: .long 0x0
0x00003fffb7dfe2b0: .long 0x0
....
It seems the entry address of the function points to a totally wrong address.
PPC-64 has a strange way of handling the function pointers. A function pointer
points to a record with three values: function entry address, r2 value (GOT),
r11 (some local GOT, I don't remember) value. This handling method is clearly
seen on the PPC64 BE:
ld r10,0(r9)
ld r11,16(r9)
ld r2,8(r9)
mtctr r10
bctrl
However, the PPC64 LE does something totally different:
std r2,24(r1)
mr r12,r9
mtctr r12
bctrl
ld r2,24(r1)
Neither r2 nor r11 is set, only r2 is saved and restored. The function pointer
is directly used.
Did they change the ABI??? What else they changed?
Anyway, there is an SLJIT_INDIRECT_CALL macro. Currenty it is set if we use
PPC64 or PPC32 on AIX.
#ifndef SLJIT_INDIRECT_CALL
#if (defined SLJIT_CONFIG_PPC_64 && SLJIT_CONFIG_PPC_64) || (defined
SLJIT_CONFIG_PPC_32 && SLJIT_CONFIG_PPC_32 && defined _AIX)
/* It seems certain ppc compilers use an indirect addressing for functions
which makes things complicated. */
#define SLJIT_INDIRECT_CALL 1
#endif
#endif /* SLJIT_INDIRECT_CALL */
Could you try forcing to disable this macro by commenting out the "#define
SLJIT_INDIRECT_CALL 1"?
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
