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.
In its current state, the patch might break non-linux x86_64 ELF platforms. The function ocAllocateSymbolExtras has to allocate space for GOT and PLT entries "next to"(1) the object code. In the non- USE_MMAP case, this boils down to a call to realloc, but with USE_MMAP, the code uses mremap, which is a Linux extension. That might be a problem that needs to be fixed.
x86_64-elf-pic.patch
Description: Binary data
Cheers, Wolfgang (1) "next to" means within +- 2GB on x86_64, and +=32MB on powerpc.
_______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
