llvm dev - Jun 2010 - [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

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

On Thu, Jun 17, 2010 at 2:54 PM, Smith, Tim <tim at bioware.com>
wrote:
> 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.
Right... the 2.6 ELFCodeEmitter is experimental code which was never
complete enough to handle options like PIC.
> Will have to get the 2.7 update and try it out.
ELFCodeEmitter is gone in 2.7; hopefully, similar functionality will
be back in 2.8 without the limitations it had in 2.6.  In the
meantime, I'd suggest simply using GNU as.

-Eli