similar to: [LLVMdev] Status of support in dwarf4

> I've built the llvm-dwarfdump tool from the 3.3 branch and ran it on simple > binary compiled with dwarf4 debug information. > > > > The tool seem to read the file correctly including dwarf information > (DIContext::getDWARFContext returns a valid context), but when trying to > access line information, all I get is "<invalid>" string for the file name

For llvm-dwarfdump we need to handle relocations inside the debug info sections in order to successfully dump the dwarf info including strings. Nick sent out a partial patch that did this not too long ago and I've taken it and gone in a bit of a different direction, but kept the same basic architecture. In place of applying the relocations to the data we've read from disk I'm keeping

I just updated from the most recent svn ToT. I'm now getting the following compilation errors. Looks like DIIContext.h needs some includes. Does anyone else see this error also? Am I missing something? In file included from DIContext.cpp:10: /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:27: error: 'uint32_t' does not name a type

On Thu, Sep 15, 2011 at 15:24, Guo, Xiaoyi <Xiaoyi.Guo at amd.com> wrote: > I just updated from the most recent svn ToT. I'm now getting the following compilation errors. Looks like DIIContext.h needs some includes. Does anyone else see this error also? Am I missing something? > > In file included from DIContext.cpp:10: >

On Mon, Nov 5, 2012 at 5:17 PM, Eric Christopher <echristo at gmail.com> wrote: > For llvm-dwarfdump we need to handle relocations inside the debug info > sections in order to successfully dump the dwarf info including strings. > Nick sent out a partial patch that did this not too long ago and I've taken > it and gone in a bit of a different direction, but kept the same basic

See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional machinery required to wrap the two interfaces, so we could move the DIContext class at that time. Does

> On Jan 29, 2015, at 10:20 AM, Zachary Turner <zturner at google.com> wrote: > > I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. > > There's still more to be done on the pdb dumping tool, but at this

> On Jan 29, 2015, at 11:08 AM, Zachary Turner <zturner at google.com> wrote: > > See my earlier response to Adrian. But I'll rehash the point here, which is that basically in the short term, I think it makes the most sense to keep them separate. In the future, if / when we decide to provide a unified interface (e.g libDebugInfo as you suggest), there will be additional

I've been working on adding pdb reading support to llvm. This started as a tool for dumping info from a pdb (similar to llvm-dwarfdump), which has been checked in and currently has limited support for dumping pdb. There's still more to be done on the pdb dumping tool, but at this point -- to reduce duplicated effort -- I think it makes the most sense to start moving some of this logic

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

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

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

> On 3 Dec 2018, at 23:01, Matthew Pickering via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Is anyone able to help me with this or suggest where I might be able > to get help? You’ve asked the right place, apologies for the delay I’m supposed to be answering these questions. > > Matt > On Mon, Nov 26, 2018 at 3:02 PM Matthew Pickering > <matthewtpickering

Hi, I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. Current interface is: class DILineInfo { const char *FileName; uint32_t Line; uint32_t Column; ... }; class DIContext { ... virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; }; First, I would like to get function name associated with the

On Sat, May 5, 2012 at 10:01 PM, Benjamin Kramer <benny.kra at googlemail.com>wrote: > > On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > > > Hi, > > > > I would like to extend DebugInfo library for the purpose of using it in > AddressSanitizer/ThreadSanitizer run-time libraries. > > > > Current interface is: > > > > class DILineInfo {

On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > Hi, > > I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. > > Current interface is: > > class DILineInfo { > const char *FileName; > uint32_t Line; > uint32_t Column; > ... > }; > > class DIContext { > ... >

Thanks for providing the experimental data! It clearly shows the value of type sections in DWARF. Regarding why type sections are off by default, aside from the issue of consumers needing to understand them, there is a size penalty to type sections that becomes more evident in smaller projects (meaning, fewer compilation units). The size penalty can be balanced against the amount of

Hi Frédéric and LLVM, I managed to finally come back to this after quite a while. Frédéric, thank you very much for the pointer to your work; it’s saving me a lot of time! Unfortunately, I am running into one issue that my knowledge isn’t complete enough to solve on my own yet. The description of D6771 reads, "It requires a few preliminary patches like landing D6243 and adding a

On 06.05.2012, at 08:01, Dmitry Vyukov wrote: > On Sat, May 5, 2012 at 10:01 PM, Benjamin Kramer <benny.kra at googlemail.com> wrote: > > On 05.05.2012, at 17:52, Dmitry Vyukov wrote: > > > Hi, > > > > I would like to extend DebugInfo library for the purpose of using it in AddressSanitizer/ThreadSanitizer run-time libraries. > > > > Current

llvm[2]: Compiling DWARFDebugArangeSet.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugAranges.cpp for Debug+Asserts build llvm[2]: Compiling DWARFDebugFrame.cpp for Debug+Asserts build /home/rkotler/llvm_trunk/lib/DebugInfo/DWARFDebugFrame.cpp:118:8: error: private field 'LinkedCIE' is not used [-Werror,-Wunused-private-field] CIE *LinkedCIE; ^ 1 error