#2805: Test ffi009(ghci) fails on PPC Mac OS X
----------------------------+-----------------------------------------------
Reporter: thorkilnaur | Owner:
Type: bug | Status: new
Priority: normal | Component: GHCi
Version: 6.11 | Severity: normal
Keywords: | Testcase: ffi009(ghci)
Architecture: powerpc | Os: MacOS X
----------------------------+-----------------------------------------------
The test ffi009(ghci) has failed for a while on PPC Msc OS X
(http://darcs.haskell.org/buildbot/all/builders/tnaur%20PPC%20OSX%20head%202/builds/156/steps/runtestsuite/logs/unexpected):
{{{
=====> ffi009(ghci)
cd ./ffi/should_run &&
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2
/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-
lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs
--interactive -v0 -ignore-dot-ghci -fglasgow-exts <ffi009.genscript
1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 98633 Illegal instruction
'/Volumes/tn18_HD_1/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx-2
/tnaur-ppc-osx-head-2/build/ghc/stage2-inplace/ghc' -fforce-recomp -dcore-
lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs
--interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript >
ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 132 )
Stdout:
Testing 5 Int arguments...
True
True
True
True
True
True
True
True
True
True
Testing 11 Double arguments...
Stderr:
*** unexpected failure for ffi009(ghci)
}}}
An extract from the so-called crash report indicates a jump into the wild:
{{{
Exception Type: EXC_BAD_INSTRUCTION (SIGILL)
Exception Codes: 0x0000000000000002, 0x00000000027ffd04
Crashed Thread: 2
...
Thread 2 Crashed:
0 ??? 0x027ffd04 0 + 41942276
1 ghc 0x012da320 setThreadLocalVar + 16
2 ghc 0x012fa87c ffi_call_DARWIN + 204
(darwin.S:131)
3 ghc 0x012fa3a0 ffi_call + 208
(ffi_darwin.c:457)
4 ghc 0x012cacb8 interpretBCO + 4984
5 ghc 0x012d46d0 schedule + 1024
6 ghc 0x012d4d84 workerStart + 84
7 libSystem.B.dylib 0x9292f658 _pthread_start + 316
}}}
When the test is run with a ghc built with {{{GhcDebugged=YES}}} (see
http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking and
{{{mk/config.mk}}}), an assertion failure is reported instead:
{{{
=====> ffi009(ghci)
cd . && '/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-
pulling-and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-
recomp -dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output
ffi009.hs --interactive -v0 -ignore-dot-ghci -fglasgow-exts
<ffi009.genscript 1>ffi009.interp.stdout 2>ffi009.interp.stderr
/bin/sh: line 1: 43988 Abort trap
'/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-complete-for-pulling-
and-copying-20070713_1212/ghc/ghc/stage2-inplace/ghc' -fforce-recomp
-dcore-lint -dcmm-lint -Dpowerpc_apple_darwin -dno-debug-output ffi009.hs
--interactive -v0 -ignore-dot-ghci -fglasgow-exts < ffi009.genscript >
ffi009.interp.stdout 2> ffi009.interp.stderr
Wrong exit code (expected 0 , actual 134 )
Stdout:
Stderr:
ffi009: internal error: ASSERTION FAILED: file Linker.c, line 4380
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
*** unexpected failure for ffi009(ghci)
}}}
The assertion failure is reported from this context in {{{Linker.c}}}:
{{{
if(reloc->r_pcrel)
{
#ifdef powerpc_HOST_ARCH
// In the .o file, this should be a relative
jump to NULL
// and we'll change it to a relative jump to
the symbol
ASSERT(word + reloc->r_address == 0);
jumpIsland = (unsigned long)
&makeSymbolExtra(oc,
reloc->r_symbolnum,
(unsigned long)
symbolAddress)
-> jumpIsland;
if(jumpIsland != 0)
{
offsetToJumpIsland = word + jumpIsland
- (((long)image) + sect->offset -
sect->addr);
}
#endif
word += (unsigned long) symbolAddress
- (((long)image) + sect->offset -
sect->addr);
}
}}}
The relocations leading to the assertion failure are required by branch
instructions generated by {{{gcc}}} for {{{ffi009_stub.c}}} that contains
expressions of the form {{{symbol+constant}}} (where {{{symbol}}} is an
external symbol) whose distance to the instruction needs to be packed into
a 24-bit field. An example is
{{{
bl saveFP+56 ; save f28-f31
}}}
and there are actually 4 cases like this in the code generated by
{{{gcc}}} for {{{ffi009_stub.c}}}.
This problem does not appear particularly easy to solve: The mechanism
used when such a branch needs to address code that cannot be addressed
using a 24-bit relative address is to create so-called jump islands, which
are small, close-by pieces of code that (hopefully, but see #1845) *can*
be reached using 24-bit relative addressing. The branch is changed to
address the jump island which, in turn, constructs the actual 32-bit
address and branches to it. Currently, however, this mechanism, for the
PPC Mac OS X architecture, is limited to a single jump island per external
symbol and is not capable of handling the addressing of external symbols
with constants added to them. Handling the adding of a constant is doable,
I believe, but the problem is that the same external symbol may appear
multiple times with different constants added. For example, in addition to
the above case, the code for {{{ffi009_stub.c}}} also includes
{{{
bl saveFP+28 ; save f21-f31
}}}
which would require creating two jump islands for the single symbol
{{{saveFP}}}.
Possible solutions:
1. Make a special case out of the specific symbols concerned here. This
would involve creating a limited list of different jump islands for these
symbols, to be used when different constants were added.
1. Generalize, somehow, the present jump island mechanism to allow more
flexibility. It is undoubtably possible to do this, but it does not seem
to be particularly easy to do.
1. The {{{-mlongjump}}} option actually causes {{{gcc}}} to replace the
critical relative brach instructions by inline code, at the expense of
generating longer and potentially slower code for all calls and possibly
other branches as well. And if we try this, we get:
{{{
ffi009: internal error:
unknown relocation 13
(GHC version 6.11.20081121 for powerpc_apple_darwin)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
}}}
(relocation type 13 is PPC_RELOC_JBSR) so Linker.c needs to be extended
to handle this type also.
Any advice on how to proceed in this matter, additional ideas and views,
would be most welcome.
Best regards
Thorkil
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2805>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
