llvm dev - Jul 2011 - [LLVMdev] [MCJIT] Why does it produce non-PIC ELF code?

ELF that MCJIT writes on x86_64 has relocations in it. Particularly, 
R_X86_64_PC32 relocations are used for the sections .gcc_except_table 
and .eh_frame related to exception processing.
I am not sure where is general documentation on relocation types, 
including R_X86_64_PC32. Looks like it's nowhere to be found on the web.
But 32-bit relocation can't be used in 64-bit code since it causes 
overflows in general case. And particularly in case of .gcc_except_table 
and .eh_frame in MCJIT-printed ELF.

So it this a bug, or I just miss something?

Another question is: Why PIC code instead isn't written by MCJIT? When I 
look at the code, it looks like the variable IsPCRel is used to 
determine if code is non-PIC, and this variable is calculated by 
isFixupKindPCRel based on some fixup types.
Is there a way to make all code PIC?

Yuri

On 07/08/2011 01:25 PM, Yuri wrote:
> ELF that MCJIT writes on x86_64 has relocations in it. Particularly,
> R_X86_64_PC32 relocations are used for the sections .gcc_except_table
> and .eh_frame related to exception processing.
> I am not sure where is general documentation on relocation types,
> including R_X86_64_PC32. Looks like it's nowhere to be found on the
web.
> But 32-bit relocation can't be used in 64-bit code since it causes
> overflows in general case. And particularly in case of .gcc_except_table
> and .eh_frame in MCJIT-printed ELF.
My guess is that it is just using the small code model, in which case 
you need to produce 32 bit relocations since that is the size available 
in the instruction (there is no call with a 64 bit immediate for example).
> So it this a bug, or I just miss something?
>
> Another question is: Why PIC code instead isn't written by MCJIT? When
I
> look at the code, it looks like the variable IsPCRel is used to
> determine if code is non-PIC, and this variable is calculated by
> isFixupKindPCRel based on some fixup types.
> Is there a way to make all code PIC?
>
> Yuri
Cheers,
Rafael

On 07/08/2011 11:28, Rafael Ávila de Espíndola wrote:
> My guess is that it is just using the small code model, in which case
> you need to produce 32 bit relocations since that is the size available
> in the instruction (there is no call with a 64 bit immediate for example).
I don't see the difference in the resulting ELF when I set Large 
CodeModel with TargetMachine::setCodeModel.

Yuri

On Fri, Jul 08, 2011 at 02:28:44PM -0400, Rafael Ávila de Espíndola
wrote:
> On 07/08/2011 01:25 PM, Yuri wrote:
> > ELF that MCJIT writes on x86_64 has relocations in it. Particularly,
> > R_X86_64_PC32 relocations are used for the sections .gcc_except_table
> > and .eh_frame related to exception processing.
> > I am not sure where is general documentation on relocation types,
> > including R_X86_64_PC32. Looks like it's nowhere to be found on
the web.
> > But 32-bit relocation can't be used in 64-bit code since it causes
> > overflows in general case. And particularly in case of
.gcc_except_table
> > and .eh_frame in MCJIT-printed ELF.
> 
> My guess is that it is just using the small code model, in which case 
> you need to produce 32 bit relocations since that is the size available 
> in the instruction (there is no call with a 64 bit immediate for example).
I don't think it is the instruction size, but essentially the assumption
that all code fits into a 2GB segment and therefore the exception tables
etc only need 32bit (signed) relocations too.

Yuri, keep in mind that R_X86_64_PC32 is relative to the instruction
pointer. It is not a fixed absolute value, so it doesn't overflow as
long as everything is mapped into one 2GB range.

Joerg