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

[Eric Christopher]

Also, needs testcases please.

Thanks!

-eric


On Thu, Jan 24, 2013 at 12:51 AM, Eric Christopher <echristo at gmail.com>wrote:

> 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/003ed4be/attachment.html>