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.