llvm dev - Jun 2010 - [LLVMdev] Relocation issue with jump tables in ELF object files on X86_64

(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.

---
Tim Smith
Principal Programmer - Austin MMO
BioWare, Edmonton Studio
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100617/325e14c5/attachment.html>

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.

-Eli

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.

-----Original Message-----
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.



-----Original Message-----
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.

-Eli

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev