search for: dwarfcontextinmemory

...dress(uint64_t)' DIContext.cpp: In static member function 'static llvm::DIContext* llvm::DIContext::getDWARFContext(bool, llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::StringRef)': DIContext.cpp:23: error: cannot allocate an object of abstract type 'llvm::DWARFContextInMemory' DWARFContext.h:88: note: because the following virtual functions are pure within 'llvm::DWARFContextInMemory': /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:52: note: virtual llvm::DILineInfo llvm::DIContext::getLineInfoForAddress(int) /bin/rm: cannot remove `/extra...

Hi, I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? -- Erik.

...64_t)' > DIContext.cpp: In static member function 'static llvm::DIContext* llvm::DIContext::getDWARFContext(bool, llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::StringRef, llvm::StringRef)': > DIContext.cpp:23: error: cannot allocate an object of abstract type 'llvm::DWARFContextInMemory' > DWARFContext.h:88: note:   because the following virtual functions are pure within 'llvm::DWARFContextInMemory': > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:52: note:   virtual llvm::DILineInfo llvm::DIContext::getLineInfoForAddress(int) > /bin/rm: cannot...

...); >> + return DebugFrame.get(); >> +} >> + >> const DWARFLineTable * >> DWARFContext::getLineTableForCompileUnit(DWARFCompileUnit *cu) { >> if (!Line) >> @@ -440,7 +465,8 @@ DIInliningInfo DWARFContext::getInlining >> } >> >> DWARFContextInMemory::DWARFContextInMemory(object::ObjectFile *Obj) : >> - IsLittleEndian(Obj->isLittleEndian()) { >> + IsLittleEndian(Obj->isLittleEndian()), >> + AddressSize(Obj->getBytesInAddress()) { >> error_code ec; >> for (object::section_iterator i = Obj->beg...

...wrote: > On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: >> Hi, >> >> I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? >> > > Pl...

On Thu, Feb 7, 2013 at 2:50 PM, Erik Verbruggen <erikjv at me.com> wrote: > Hi, > > I noticed that llvm-dwarfdump does not show any information about the eh_frame section. While DWARFContext::getDebugAranges explicitly tries to parse it, it fails because the DWARFContextInMemory constructor does not check for that specific section name. A fix would be to check wether the name is "debug_frame" or "eh_frame". If this is correct, should I submit a smallish patch, or could somebody else fix it, or can I just commit the change to svn? > Please submit a p...

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...

...t;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...

...rking with the IR language, but directly in C++ with IRBuilder::CreateAlloca. My goal is that one : - Generate machine code with an instance of the class 'IRBuilder' - Emit 'ObjFile' class instance with MCJIT - Create a DwarfContext instance directly from the emitted ObjFile object (DwarfContextInMemory) (on JitEventListener::NotifyObjectEmitted) - Use this DwarfContext to step into my home made runtime debugger. Now I can perform step over/into/out in my debugger using the DwarfContext instance without problem, but I'm still stuck on how to watch my local variables in my debugger (i can'...

...y simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had submitted a patch that I aborted as it was too large. One of the issues with the patch was a stand alone DWARF generator that can turn a few API calls into the section data required for the DWARFContextInMemory class to be able to load DWARF from. The idea is to generate a small blurb of DWARF, parse it using our built in DWARF parser and validate that the API calls we do when consuming the DWARF match what we expect. The original stand along DWARF generator class is in unittests/DebugInfo/DWARF/DWARFGene...

...t directly in C++ with > IRBuilder::CreateAlloca. > My goal is that one : > - Generate machine code with an instance of the class 'IRBuilder' > - Emit 'ObjFile' class instance with MCJIT > - Create a DwarfContext instance directly from the emitted ObjFile object > (DwarfContextInMemory) (on JitEventListener::NotifyObjectEmitted) > - Use this DwarfContext to step into my home made runtime debugger. > > Now I can perform step over/into/out in my debugger using the DwarfContext > instance without problem, but I'm still stuck on how > to watch my local variables in...

...nes that test DWARF forms currently. I would like to expand this to include many more tests. > > I had submitted a patch that I aborted as it was too large. One of the issues with the patch was a stand alone DWARF generator that can turn a few API calls into the section data required for the DWARFContextInMemory class to be able to load DWARF from. The idea is to generate a small blurb of DWARF, parse it using our built in DWARF parser and validate that the API calls we do when consuming the DWARF match what we expect. The original stand along DWARF generator class is in unittests/DebugInfo/DWARF/DWARFGene...

...d like to expand >> this to include many more tests. >>> >>> I had submitted a patch that I aborted as it was too large. One of the >> issues with the patch was a stand alone DWARF generator that can turn a >> few API calls into the section data required for the DWARFContextInMemory >> class to be able to load DWARF from. The idea is to generate a small blurb >> of DWARF, parse it using our built in DWARF parser and validate that the >> API calls we do when consuming the DWARF match what we expect. The >> original stand along DWARF generator class is in...

...; this to include many more tests. > >>> > >>> I had submitted a patch that I aborted as it was too large. One of the > >> issues with the patch was a stand alone DWARF generator that can turn a > >> few API calls into the section data required for the > DWARFContextInMemory > >> class to be able to load DWARF from. The idea is to generate a small > blurb > >> of DWARF, parse it using our built in DWARF parser and validate that the > >> API calls we do when consuming the DWARF match what we expect. The > >> original stand along DW...

Binding the alloca to the debug-info metadata is not automatic. You need to emit an intrinsic function call to llvm.dbg.declare to bind the two together. If you are simply trying to emit DWARF for your program, the rest of the processing should already be in place for that. If you are trying to do something else, you would need to describe that so we understand what you need. --paulr From:

Hi, First, considering I'm using an IRBuilder and a DIBuilder to build my program, how can I automatically bind the CreateAlloca with my named local variable inside the DIBuilder ? Is it automatic with the Twine name of CreateAlloca ? And/Or should I use DIBuilder::createAutoVariable and how ? Then, I'm wondering how to locate back my local variable in memory (register or stack) once i

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,

On 04/29/2013 15:53, Keith Walker wrote: > It sounds like you are trying to load the DWARF sections into target memory .... and if so I guess I would have to ask you why as they are not normally loaded into target memory? You are right, debug sections aren't normally loaded into the memory together with the sections needed for running. However, I am mostly focusing on the (lightweight)

...StringRef lineSection, StringRef stringSection, - StringRef rangeSection) { + StringRef rangeSection, + const RelocAddrMap &Map) { return new DWARFContextInMemory(isLittleEndian, infoSection, abbrevSection, aRangeSection, lineSection, stringSection, - rangeSection); + rangeSection, Map); } diff --git a/lib/DebugInfo/DWARFContext.h b/lib/DebugInfo/DWARFContex...

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