Kaylor, Andrew
2013-Jan-11 00:42 UTC
[LLVMdev] DebugInfo library and relocations in the .debug_line section
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>
Eric Christopher
2013-Jan-11 15:56 UTC
[LLVMdev] DebugInfo library and relocations in the .debug_line section
On Thu, Jan 10, 2013 at 4:42 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote:> 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.**** > > ** >*shrug* I've been adding them as needed. I knew I needed the debug_line table, but I've been mostly adding that stuff as I need it to fix something else. Right now I think we're only going to ultimately need a couple of them so just adding them as fields sounds fine.> ** > > 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.**** > > ** >Oh sorry :)> ** > > 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? >That's pretty much correct, I don't really need to dump the line tables at the moment, but it shouldn't be too long if you're not in any hurry. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/762cb9d6/attachment.html>
Kaylor, Andrew
2013-Jan-11 19:21 UTC
[LLVMdev] DebugInfo library and relocations in the .debug_line section
Alright. I'll probably take a shot at it once I have the more general stuff for my event handler working and ready for review. -Andy From: Eric Christopher [mailto:echristo at gmail.com] Sent: Friday, January 11, 2013 7:57 AM 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 4:42 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote: 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. *shrug* I've been adding them as needed. I knew I needed the debug_line table, but I've been mostly adding that stuff as I need it to fix something else. Right now I think we're only going to ultimately need a couple of them so just adding them as fields sounds fine. 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. Oh sorry :) 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? That's pretty much correct, I don't really need to dump the line tables at the moment, but it shouldn't be too long if you're not in any hurry. -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130111/7462fc51/attachment.html>
Apparently Analagous Threads
- [LLVMdev] DebugInfo library and relocations in the .debug_line section
- [LLVMdev] DebugInfo library and relocations in the .debug_line section
- [LLVMdev] DebugInfo library and relocations in the .debug_line section
- [LLVMdev] DebugInfo library and relocations in the .debug_line section
- [LLVMdev] DebugInfo library and relocations in the .debug_line section