[LLVMdev] DebugInfo library and relocations in the .debug_line section

[Eric Christopher]

On Thu, Jan 10, 2013 at 3:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:

>  Actually, MCJIT doesn’t perform relocations on debug sections.  I’m not
> sure that would matter anyway.  The place where I’m handling the debug
> information is outside MCJIT and the MCJIT relocation code isn’t really
> accessible at that point.****
>
> **
>

I know it doesn't, that's why I made the "non-alloc" comment. :)


> **
>
> Right now, when MCJIT emits an object image, it broadcasts an event to any
> registered listeners indicating that an object was emitted, passing an
> ObjectImage reference as the parameter to the listener.  The only current
> listener I’m aware of is the IntelJITEventListener, which wants to notify
> the Intel VTune Amplifier (if present) about the newly JITed functions.***
> *
>
> **
>

OK.


> **
>
>
>
> The problem is that I have a test case that is trying to reference an
> inlined function.  In this case, the generated object puts the ‘inlined’
> function in a separate section (I’m not clear why that is) and generates
> relocations for the .debug_line section.  Since these relocations are never
> applied, I end up with multiple sequences in the line table claiming to be
> at address zero.****
>
> ** **
>
> FWIW, if I use whatever ‘dwarfdump’ is on my Linux box to look at the
> generated object, it shows me a line table with multiple entries claiming
> to be at address zero just like llvm-dwarf does.  If I let clang finish
> things and create an executable, both dwarfdump and llvm-dwarfdump show
> unique load-based addresses for everything.****
>
> **
>
Right. This is pretty easy, especially if you just look at my last patch
that added a new reloc handler for .debug_info.dwo (r171428). I've been
meaning to do this, but it hasn't bubbled up to the top of my queue yet.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130110/bfa4ec80/attachment.html>