search for: dilineinfo

...kspace/llvm/include/llvm/DebugInfo/DIContext.h:34: error: 'uint32_t' does not name a type /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:35: error: 'uint32_t' does not name a type /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h: In constructor 'llvm::DILineInfo::DILineInfo(const char*, int, int)': /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:31: error: class 'llvm::DILineInfo' does not have any field named 'Line' /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:31: error: class 'llvm::DILineInfo' d...

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 address. Then, I would like to get inlined frames as well. Then, I would...

...rote: > > 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 { > > ... > > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > > }; > > > > First, I would...

...m/include/llvm/DebugInfo/DIContext.h:34: error: 'uint32_t' does not name a type > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:35: error: 'uint32_t' does not name a type > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h: In constructor 'llvm::DILineInfo::DILineInfo(const char*, int, int)': > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:31: error: class 'llvm::DILineInfo' does not have any field named 'Line' > /extra/xguo/workspace/llvm/include/llvm/DebugInfo/DIContext.h:31: error: class 'llvm::DILineI...

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 { > ... > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > }; > > First, I would like to get function name associated with the address. &gt...

...t; 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 { > > const char *FileName; > > uint32_t Line; > > uint32_t Column; > > ... > > }; > > > > class DIContext { > > ... > > virtual DILineInfo getLineInfoForAddress(uint64_t address) = 0; > > }; > > > > First, I would...

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

..." > +#include "llvm/Support/FileSystem.h" > +#include "llvm/Support/Mutex.h" > +#include "llvm/Support/MutexGuard.h" > +#include "llvm/Support/raw_ostream.h" > + > +using namespace llvm; > +using namespace llvm::object; > +typedef DILineInfoSpecifier::FileLineInfoKind FileLineInfoKind; > + > +namespace { > + > +// language identifier (XXX: should we generate something better from debug info?) > +#define JIT_LANG "llvm-IR" > +#define LLVM_PERF_JIT_MAGIC ((uint32_t) 'J' << 24 | (uint32_t) 'i&...

Having something like this available in tree would definitely be useful. For simplicity, why don't we start with support for the second style? This is the long term useful one and would be a good starting point for getting the code in tree. Can you give a pointer to the patch so that I can assess the rough complexity? If it's simple enough, I'd be happy to help get it reviewed

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

Hi, On 2016-12-29 13:17:50 -0800, Philip Reames wrote: > Having something like this available in tree would definitely be > useful. Cool. > For simplicity, why don't we start with support for the second style? This > is the long term useful one and would be a good starting point for getting > the code in tree. Works for me. > Can you give a pointer to the patch so that

Hi, In a 32-bit ARM build, I am seeing the following warning (edited for simplicity, I can provide full logs if necessary): > llvm-objdump -l -d -x file.elf > llvm-objdump: warning: 'file.elf': failed to parse debug information for file.elf All object files and static libraries seem to have debug info (i.e., llvm-objdump does not complain when run on each file individually and