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

[Kaylor, Andrew]

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.

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.

The listener uses the ObjectImage interface (which is modeled after the ObjectFile interface) to walk through the symbols in the object and look for functions, getting their address and size from the SymbolRef interface.  So far, so good, and all of this is currently happening in trunk.

As a next step, I want to use the DWARF information to figure out source file and line number information for the functions.  My plan is to add a new function to the DIContext interface called getLineInfoForAddressRange, which will do pretty much what the existing getLineInfoForAddress does except that it will return a vector of <address, DILineInfo> pairs for all lines in the range.

It happens that the ObjectImage class aggregates an ObjectFile, so I'm going to provide a method to retrieve the underlying ObjectFile and use that to create the DIContext.  That works.  I'm having a bit of an issue with the getLineInfoForAddress function in that it seems to be expecting addresses that are offsets into the function's section rather than into the file.  This seems wrong and may or may not be related to the fact that the generated object doesn't have a .debug_aranges section and so the DWARFContext code constructs that on the fly.  In any event, I've got that working for at least simple cases where all the JITed functions are in the same section.

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.

I can send you .cpp, .bc, .ll or .o files for my test case if that would help.

Thanks,
Andy

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

That relocation handling is only done for the llvm-dwarfdump binary. MCJIT handles relocations a bit different. I think you just need to go ahead and allow the MCJIT relocation handling machinery to work on non-alloc sections and it should go ahead and handle these just fine, unless you're using the existing stuff in lib/DebugInfo to print out information or something?

If this isn't what you're doing can you give me a bit more information on your current code?

-eric

On Wed, Jan 9, 2013 at 4:53 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:
I'm working on adding source-based profiling support for MCJIT and in the process of implementing this, I came across a test case where an object is being generated that wants to have relocations applied to the .debug_line section.  I see in the DebugInfo code that it currently only supports relocations applied to either the .debug_info or the .debug_info.dwo section.

Can anyone give me an overview of what I would need to do to extend this to handle the .debug_line section also?

Thanks,
Andy

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