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

[Kaylor, Andrew]

Well, I saw the .debug_info.dwo stuff (though I didn't realize it was so recent), but it wasn't clear to me how adding a map for a section with a different purpose would work -- that is, whether it should be yet another member variable in DWARFContextInMemory or if there was some better way to combine them.

It also wasn't clear to me what the relocation map was doing anyway and what would need to be changed for the .debug_line section, but I suppose that was mostly laziness on my part, hoping that you had a plan that you could just spell out for me.

Having overcome my laziness a bit today and looked at the code some more, it looks like I'd need to pass the new map (however it was stored) into DWARFDebugLine and have that class use it in its parseStatementTable and associated methods.  It looks like it would take a bit of thought to figure out which fields might be candidates for relocation and which wouldn't, but I suppose that's manageable.

Does this sound basically correct?  Or should I just wait for you to do the work? :)

-Andy


From: Eric Christopher [mailto:echristo at gmail.com]
Sent: Thursday, January 10, 2013 3:24 PM
To: Kaylor, Andrew
Cc: llvmdev at cs.uiuc.edu; Jim Grosbach
Subject: Re: DebugInfo library and relocations in the .debug_line section



On Thu, Jan 10, 2013 at 3:13 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto: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/20130111/4121ef11/attachment.html>