<div dir="ltr">LGTM, thanks!<div><br></div><div>-eric</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 3:29 PM, Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">This patch adds support for handling relocations in the .debug_line section to the DebugInfo module by adding a RelocAddrMap object to capture the relocations when a DWARFContextInMemory object is created and passing that map to the DWARFDebugLine
 class when it is created so that the relocations can be applied on the fly when the .debug_line section is read from memory.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">This patch is independent of the patch I submitted last week to add a function for getting line numbers for an address range.  I’ll be resubmitting a refactored version of that patch shortly that isolates the changes to DebugInfo.<u></u><u></u></p>

<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The patch does not attempt to exhaustively handle all access to the .debug_line section, but rather handles only the specific location that is likely to require application of relocations (the DW_LNE_set_address command).  I think it is
 likely that this is the only place where relocations will occur in the .debug_line section.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The patch also slightly modifies the existing handling of relocations when processing an ELF object file in such a way as to capture the intended relocation value (that is, the address of the symbol being used in the relocation) and passing
 that to the RelocVisitor that calculates the target value for the relocation.  I believe that in the case of object files being read from disk the symbol address will be reported as zero, and so the behavior will be the same as it currently is.  However, in
 the case of an object file that has been emitted and loaded by MCJIT (and subsequently passed to a JIT event listener), the address will be the address where the symbol was loaded into memory.  This is important for avoiding duplications in the address ranges
 and line table when there are multiple code sections.  I can provide more details and a test case for that on request.  I will be submitting a test case as part of a subsequent patch.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-Andy<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

</blockquote></div><br></div>