[LLVMdev] Relocation issue with jump tables in ELF object files on X86_64

[Smith, Tim]

We generating object files, not using the JIT so I don't know if those fixes applies in our case.  

As far as using PIC goes, the ELFCodeEmitter has asserts to tell you that PIC isn't currently supported.

Will have to get the 2.7 update and try it out.

Thanks.

-----Original Message-----
From: Howell, Nathan [mailto:nhowell at ebay.com] 
Sent: Thursday, June 17, 2010 3:45 PM
To: Eli Friedman; Smith, Tim
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] Relocation issue with jump tables in ELF object files on X86_64

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