<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 4:40 PM, Yuri <span dir="ltr"><<a href="mailto:yuri@rawbw.com" target="_blank">yuri@rawbw.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 04/29/2013 15:53, Keith Walker wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote>
<br></div>
You are right, debug sections aren't normally loaded into the memory together with the sections needed for running.<br>
<br>
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.<br>

<br>
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.</blockquote><div><br></div>
<div style>I'll bite:</div><div style>1. It's smaller (not everything is leb128 in dwarf)</div><div style>2. It's faster to process as a result.</div><div style>3. It offers almost no disadvantages in practice</div>
<div style><br></div><div style><br></div><div style>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.</div><div style>
<br></div><div style>What would the advantages to using dwarf-64 by default be, exactly?  </div><div style><br></div><div style>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.</div>
<div style><br></div></div></div></div>