[llvm-commits] [PATCH] [Review Request] Adding support for relocation in the .debug_line section to DebugInfo

[Eric Christopher]

LGTM, thanks!

-eric


On Mon, Jan 21, 2013 at 3:29 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

>  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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> -Andy****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130124/22c52684/attachment.html>