Wolfgang Thaller wrote:
On Sep 19, 2007, at 9:23 PM, Sven Panne wrote:
On Wednesday 19 September 2007 00:41, Wolfgang Thaller wrote:
I guess I could find some time to play around with it on the weekend.
I don't have an x86_64-linux box available right now, but I might
either try some virtualisation software or just do a rough sketch and
leave you to do the debugging ;-). [...]
Deal! :-)
Attached is a preliminary patch. I did use virtualisation software after
all, but it's not perfect yet. I won't have a lot of time to work on
this for the next two weeks at least, so I'll just dump it on you for
now...
I've implemented the R_X86_64_GOTPCREL and R_X86_64_PLT32 relocations
using the SymbolExtra mechanism that was already in use for
powerpc-darwin, powerpc-linux and x86_64-darwin.
We need to decide what to do about non-PIC object files. I have removed
the existing x86_64_high_symbol hack and replaced it by a simpler hack,
and I've wrapped an #ifdef around the hack for now. We have two options:
if we remove the hack, we cannot load any non-PIC objects at all, but
with the hack, non-PIC objects that import data from shared libraries
will *silently* fail (as they do now). The problem is that I don't know
of a way to find out whether an out-of-range relocation refers to code
or data, so I don't know of a way to insert jump islands for code
references and still report out-of-range data references.
Right, that's exactly the reason we don't emit any useful diagnostics right
now (you'll have to take my word for it, but I really did want to avoid
making this fail silently!). It's not really possible to do anything at
compile-time either, because the data refs might just as well be from C
code as from Haskell code.
Perhaps emitting a warning for 'foreign import "&foo"' on x86_64 without
-fPIC is better than nothing. Perhaps in the future -fPIC should become
the default on x86_64 anyway.
I'm not sure whether -fPIC is completely working right now - Clemens is
still working on it, I believe, but we certainly don't test it in any of
our standard builds.
Thanks for the patch Wolfgang, we'll test and incorporate.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
