similar to: [LLVMdev] llvm compilation error on TOT

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

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

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

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

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

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

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

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

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

Hi Paul, How can i make this call to intrinsic from the c++ code ? I'm not working 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

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

Hi, 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 and 0's for line and column

On Feb 11, 2013, at 18:13, Eli Bendersky <eliben at google.com> 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

"IR" often refers to the general concept/semantics, not only the textual format in .ll files (there are 3 main forms - bitcode, textual IR, and the in-memory representation (llvm::Module, etc - constructed using IRBuilder)). A great place to start is to look at what Clang does to produce debug info - it uses IRBuilder, for instance. So you could look at how Clang uses the IRBuilder when

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

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had

> 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