similar to: [LLVMdev] llvm-dwarfdump and eh_frame

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

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

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

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

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

Hello, I'm trying to fix a long standing issue we are having in Julia where when the file information switched, we weren't recording that correctly, so line information showed up in the wrong file. Basically we would always create a scope with the DISubprogram and the given line number. What I tried was to change the scope to be a DIFile instead so we'd get the correct file

Sorry, I didn't have a small IR example and I was sure I was just doing something stupid. Thanks for the help, I'll try it out and report back. Maybe it would be good to add an assertion or something that tells people what's wrong in this case, since the generated DWARF seems to be invalid? On Wed, Aug 13, 2014 at 5:53 PM, David Blaikie <dblaikie at gmail.com> wrote: > Use

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

No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers

Oh, I see. Sorry I misunderstood. I'll try to come up with some minimal IR. The assertion stems from the fact that getCompileUnitDIE() returns null and then crashes at DWARFUnit.cpp:301. I admit I don't know if this problem is on the parsing or the generation side. While I come up with the IR, basically what I was doing was using a DebugLoc with scope being a DIFile rather than a

Hi, There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr and will degrade search from binary to linear. As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused

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 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 All, We have a local change in the X86AsmPrinter that outputs a section containing metadata on function stack sizes. We use this to measure changes to stack size between versions of the compiler and it also allows our licensees to do the same for their code. The section simply contains pairs of function symbol references (8 byte) and stack sizes (unsigned LEB128). We would like to

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

"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

Tom (and Andy, Owen, Evan, Nadav), I'd like the following commits placed into the 3.4.1 branch. I've attempted to sort this list by code owner: Andrew Trick: r203719 - PR17473 r203725 - This test need the X86 backend, move it to the X86 sub directory. [adjusts the test location from r203719] r202273 - Fix PR18165: LSR must avoid scaling factors that exceed the limit on truncated use.

> On Nov 17, 2016, at 3:40 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Thu, Nov 17, 2016 at 3:12 PM Greg Clayton via llvm-dev <llvm-dev at lists.llvm.org> wrote: > 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