#2805: Test ffi009(ghci) fails on PPC Mac OS X
-----------------------------+----------------------------------------------
Reporter: thorkilnaur | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: GHCi | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: ffi009(ghci) | Os: MacOS X
Architecture: powerpc |
-----------------------------+----------------------------------------------
Comment (by thorkilnaur):
You are right: The limitations in Linker.c (for example, that it is unable
to handle relocations of {{{external symbol+constant}}}) apply to any
compiled code that we try to load up into GHCi. So, for example, to
trigger this problem, we could code some C function with lots of
{{{double}}} arguments and try to call that function from Haskell using
GHCi. And to work around this, assuming we had implemented the
PPC_RELOC_JBSR relocation type, we would require the C function to be
compiled with {{{-mlongcall}}}.
I have implemented rudimentary PPC_RELOC_JBSR support that simply always
uses the branch island and with {{{-optc-mlongcall}}} added to the
{{{ffi009}}} test case, the test succeeds. To complete this workaround, I
would suggest that we change the {{{ASSERT(word + reloc->r_address ==
0);}}} into an actual error message that, perhaps, advices the use of the
{{{-mlongcall}}} option.
But I am still uncertain about which direction to take here. Using the
{{{-mlongcall}}} option solves the problem in the present case, but there
is no guarantee that it will continue to do so in the future. The fact
that the {{{bl xxxxFP+yy}}} instructions are replaced by inline code when
using {{{-mlongcall}}} is not documented, as far as I have been able to
tell. Some other mechanism could be used in later {{{gcc}}} versions. In
addition, man gcc says:
{{{
-mlongcall
...
In the future, we may cause GCC to ignore all longcall
specifica-
tions when the linker is known to generate glue.
}}}
where the "glue" is code, like the jump islands generated by Linker.c, to
enable branching with a 24-bit relative address to reach any 32-bit
address via a branch island. So, ultimately, we may have to do this
anyway.
Another idea which I have not looked into at all would be to try to use
the linker itself to do all these complex things, instead of having to
duplicate the functionality ourselves.
As before, any advice, comments, views, new ideas about how to proceed
with this are most welcome.
Best regards
Thorkil
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2805#comment:2>
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
