[LLVMdev] How to prevent LLVM from emitting R_X86_64_32 ELF relocations?

Robinson, Paul Paul_Robinson at playstation.sony.com
Mon Apr 29 15:57:42 PDT 2013


> -----Original Message-----
> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]
> On Behalf Of Yuri
> Sent: Monday, April 29, 2013 1:30 PM
> To: Keith Walker
> Cc: LLVM Developers Mailing List
> Subject: Re: [LLVMdev] How to prevent LLVM from emitting R_X86_64_32 ELF
> relocations?
> 
> On 04/29/2013 09:12, Keith Walker wrote:
> > You only need to go to 64-bit DWARF when your debugging information
> becomes
> > too large to fit in 32-bit DWARF tables.
> 
> I am not sure if this is true.
> Currently R_X86_64_32 EL relocations are issued for DWARF-32 debug info
> sections. This is because the size of address in DWARF-32 is only
> 32-bits, according to the above mentioned specification. Such
> relocations can't be resolved (without overflow) when the base address
> is 64-bit and higher than 4GB threshold.

References from one DWARF section to another DWARF section will use
R_X86_64_32, but references from a DWARF section to (say) .text or .data
should use 64-bit relocations.  This is how DWARF makes the distinction
between the DWARF format (32-bit) and the target-address-size (64-bit).

The DWARF sections normally aren't loaded into process memory, the way
.text and .data are; so whatever "base address" you are using for the
other sections really should not apply to the DWARF sections.

> 
> So I have to always load such ELFs into the space within the first 4GB,
> otherwise relocation resolver will fail with overflow.
> 
> Yuri
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev





More information about the llvm-dev mailing list