[LLVMdev] Relocation issue with jump tables in ELF object files on X86_64
nhowell at ebay.com
Thu Jun 17 14:44:40 PDT 2010
I had this problem a while back and received this response from Jeffrey. FWIW this is fixed in 2.7 by defaulting to CodeModel::Large and using indirect (far) calls.
From: Jeffrey Yasskin [mailto:jyasskin at google.com]
Sent: Monday, December 07, 2009 11:32 AM
To: Howell, Nathan
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] 2.6 JIT using wrong address for external functions
I had that problem too: http://llvm.org/bugs/show_bug.cgi?id=5116. To
work around the problem, you can:
* Switch to the thread-unsafe lazy jit.
* Allocate your JIT code within 2GB of your text segment.
* Find a way to look up the external function with dlsym or maybe the
ExecutionEngine's LazyFunctionCreator instead of addGlobalMapping.
* Upgrade to the top of the svn tree.
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Eli Friedman
Sent: Thursday, June 17, 2010 1:06 PM
To: Smith, Tim
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Relocation issue with jump tables in ELF object files on X86_64
On Thu, Jun 17, 2010 at 12:38 PM, Smith, Tim <tim at bioware.com> wrote:
> (llvm 2.6)
> We have an application where we are using LLVM to generate ELF object files
> for X86_64. At runtime we load these objects files into memory using our
> own ELF loader.
> Everything is working except for the jump tables.
> The ELF emitter is generating JMPQ instructions using
> X86::reloc_absolute_word_sext relocations which we are unable to patch to
> the jump table in the .rodata segment unless we force that segment to load
> in the low 2GB of the address range. Currently we just request pages of
> memory from the OS and that memory is much deeper in the address space.
> Is there proper way to patch the address or instruction (ewww) or have the
> ELF emitter generate a RIP based instruction. If a real linker doesn't
> patch the instruction, does the ELF loader always try to load .rodata
> segments in the low 2GB of memory regardless of if it is from the main image
> or from a shared library?
> Thanks for any help.
Perhaps you're missing a call to TargetMachine::setRelocationModel?
It sounds like you need PIC codegen.
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev