similar to: [LLVMdev] Creating debug information via llvm-c

Unfortunately this is what I'm already doing, and it's not working. I drew inspiration from a disassembly of a program that showed that struct foo { int a; float b; char buf[80]; } struct foo get_foo(void) { foo f = { 5, 2.5 }; return f; } would turn into define void @get_foo(%struct.foo* sret %agg.result) nounwind ssp { ... call void @llvm.memcpy.p0i8.p0i8.i64(i8* %2, i8*

On Dec 6, 2011, at 4:13 PM, Devang Patel wrote: > Hi Josh, > > On Dec 4, 2011, at 9:33 PM, Josh Matthews wrote: > >> I'm working on generating debug information for Rust, and I'm >> currently stumped on how to generate DWARF output via LLVM that will >> correctly represent this (eg. when exiting from foo2(), I'd like to >> see "Value returns

On 2008-10-11 00:34, Evan Cheng wrote: > On Oct 10, 2008, at 1:43 PM, John Criswell wrote: > > >> Dear All, >> >> Are there a set of libraries for easily manipulating the LLVM debug >> information? For example, given an Instruction *, is there an >> interface >> that will find the nearest llvm.dbg.stoppoint(), or given an alloca, >> is

Hi Jim, Thanks for the advice. Since I'm using LLVM 2.9 style of debug information. Will this code benefit from those improvement or should I generate LLVM 3.0 style of debug information ? Best Regards Seb 2012/3/6 Jim Grosbach <grosbach at apple.com> > > On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > > Hi all, > > Anyone have ideas/info on

On Thu, Jul 26, 2012 at 5:25 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Paweł, >> I have a problem that was reported some time ago but never received >> any solution. > > probably the reason that there is no action is surely that the old JIT > implementation is being replaced with the new MCJIT implementation, so > no-one feels very motivated to fix the old

Hi all, Anyone have ideas/info on this topic ? Thanks Seb 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting > x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout = >

Hi paulr: Thanks for your kindly response. Maybe I don't describe my question cleanly, let me show more information. From my side, I notice that whether we are in the continue keyword mode or we are in the right brace mode, the target of br instruction is the same, i.e. for loop Continue Keyword Mode: ; <label>:6: ; preds = %3 br label

On Oct 10, 2008, at 1:43 PM, John Criswell wrote: > Dear All, > > Are there a set of libraries for easily manipulating the LLVM debug > information? For example, given an Instruction *, is there an > interface > that will find the nearest llvm.dbg.stoppoint(), or given an alloca, > is > there an interface for getting its source level information by tracing > it to

On Mar 6, 2012, at 5:31 AM, Seb <babslachem at gmail.com> wrote: > Hi all, > > Anyone have ideas/info on this topic ? > Thanks > Seb > > 2012/3/2 Seb <babslachem at gmail.com> > Hi all, > > I'm using my own front-end to generate following code .ll file targeting x86 32-bit: > > ; ModuleID = 'check.c' > target datalayout =

Dear All, Are there a set of libraries for easily manipulating the LLVM debug information? For example, given an Instruction *, is there an interface that will find the nearest llvm.dbg.stoppoint(), or given an alloca, is there an interface for getting its source level information by tracing it to a llvm.dbg.declare()? As far as I know, no such utility interfaces exist. While I can role my

Thanks Devang. Is there any plan on making this implicit in the node creation? Or instead of using DebugLoc in SelectionDAG, use SDDbgValue's instead, or embedding the SDDbgValue in the debug loc itself somehow? This seems like something that shouldn't have to be handled on a case by case basis in the backends. Your thoughts? Thanks, Micah From: Devang Patel [mailto:dpatel at

John, Mem2reg actually modifies debug information in a way that at least suggests it's trying to maintain debugability. Specifically, it changes llvm.dbg.declare() calls (appropriate for variables that permanently reside in a single place) to llvm.dbg.value() calls (specifying that at this instant, this variable is in this register). In fact, the .bc after inlining and mem2reg

Suppose I have fun.h as: static void fun() { int a =10; } Now I have two files foo.c and goo.c as foo.c : #include "fun.h" void foo() { fun(); } goo.c: #include "fun.h" void goo() { fun(); } I get .bc files for foo.c and foo.bc through clang. Now I run llvm-ld with -disable-opt for foo.bc and goo.bc. In the resulting .bc files, one of the

The Rust compiler defines all functions as returning void, with the first parameter being an outparam of the declared return type, ie. fn foo2() -> int { ret 5; } becomes define void @_ZN4foo217_5cb557d30658848cE(i64*, { i64, { %tydesc*, i1, {} } }*) uwtable { store i64 5, i64* %0 ret void } I'm working on generating debug information for Rust, and I'm currently stumped on how

Hi, I had a problem with LLVM not emitting local variable info, even though I had calls to llvm.dbg.define. After some tracking I found that the llvm.dbg.declare (and probably value too) have to have a !dbg !nr after them to get emitted at all. maybe someone can adjust http://llvm.org/docs/SourceLevelDebugging.html#format_common_declare that the two llvm.dbg. functions need a !dbg line info

- old Keno +current Keno > On Jun 19, 2017, at 2:59 PM, Adrian Prantl <aprantl at apple.com> wrote: > > In your example the instructions in the cloned function have debug locations belonging to a different function, and the function itself is missing a DISubprogram metadata attachment. > >> (lldb) p OldFunc->dump() >> >> ; Function Attrs: nounwind optsize

On Apr 15, 2011, at 2:21 PM, Villmow, Micah wrote: > John/Richard, > I think I have found the problem to why the debug information is getting destroyed. The problem is in SelectionDAG and how it interacts with the SDDbgValue nodes and custom SDNodes. > > When the dbg_value intrinsic is encountered, it adds the debug value to a specific SD Node in

Hi all, I'm using my own front-end to generate following code .ll file targeting x86 32-bit: ; ModuleID = 'check.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32" target triple = "i386-pc-linux-gnu" @.str581 = internal constant [52 x i8] c"---- test number %d

> > On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello all, > > I would like to enhance LLVM debug info that supports setting > breakpoint on labels in function. > > Generally, if users use GDB as their debugger, they could set > breakpoints on labels in function. Following is an example. > > // C

On Fri, Mar 30, 2018 at 12:05 AM, Adrian Prantl <aprantl at apple.com> wrote: >> >> On Mar 27, 2018, at 7:41 PM, Hsiangkai Wang via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hello all, >> >> I would like to enhance LLVM debug info that supports setting >> breakpoint on labels in function. >> >> Generally, if users use GDB