llvm dev - Apr 2013 - [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.

So I have to always load such ELFs into the space within the first 4GB, 
otherwise relocation resolver will fail with overflow.

Yuri

The size of an address on the target machine in the 32-bit DWARF format is NOT
restricted to 32-bits.  The size of an address on the target machine is
specified in the DWARF table headers.

For example, in the DWARF-3 Specification, section 7.5.1, the unit_length field
is used to specify whether the DWARF format is 32-bit or 64-bit (as well as
defining the length of the table).   However the address_size field is used to
specify the size of an address on the target machine.

So whether the DWARF format is 32-bit or 64-bit is independent of the size of
addresses on the target machine as they are specified by different fields.

It sounds like you are trying to load the DWARF sections into target memory ....
and if so I guess I would have to ask you why as they are not normally loaded
into target memory?

Keith

-----Original Message-----
From: Yuri [mailto:yuri at rawbw.com]
Sent: 29 April 2013 21:30
To: Keith Walker
Cc: Jiong Wang; 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.

So I have to always load such ELFs into the space within the first 4GB,
otherwise relocation resolver will fail with overflow.

Yuri



-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium.  Thank you.

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

On 04/29/2013 15:53, Keith Walker wrote:
> It sounds like you are trying to load the DWARF sections into target memory
.... and if so I guess I would have to ask you why as they are not normally
loaded into target memory?
You are right, debug sections aren't normally loaded into the memory 
together with the sections needed for running.

However, I am mostly focusing on the (lightweight) ELF injection of the 
relocable ELF objects (ET_REL), and loading them into the memory as a 
whole, bypassing file, is often the easiest way of working with them. 
When debug info is needed, it has to be loaded into memory by debugging 
tools anyway. And it has to be relocated, so debugging tools have then 
to make sure they are placed into the lowest 4G portion for DWARF-32 
debug info. So having DWARF-32 either forces abandoning the simple 
monolithic mount of the ELF at arbitrary address, and treating debug 
info separately, or just placing the whole ELF into the lowest 4G.

So, in case when it is preferable to load the whole ELF together 
monolithically, R_X86_64_32 entries stand in the way. I am not sure why 
llvm has to use DWARF-32 by default on x86_64 architectures.

Yuri