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

[Daniel Berlin]

On Mon, Apr 29, 2013 at 4:40 PM, Yuri <yuri at rawbw.com> wrote:

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


I'll bite:
1. It's smaller (not everything is leb128 in dwarf)
2. It's faster to process as a result.
3. It offers almost no disadvantages in practice


Certainly, it doesn't have to use it (though, as others mentioned, llvm
doesn't support 64 bit dwarf), but it makes a lot of sense, given the
advantages.

What would the advantages to using dwarf-64 by default be, exactly?

IE what problem does it solve besides the above, which seems to be handled
fine by all current debuggers, and even folks with multi-gigabyte debug
info haven't complained.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130429/3de1e76e/attachment.html>