similar to: [LLVMdev] llvm debug information

Hi All, Today, debugging information is encoded in LLVM IR using various llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple, !1 = metadata !{i32 458769, i32 0, i32 12, metadata !"foo.c", metadata !"/tmp", metadata !"clang 1.0", i1 true, i1 false, metadata !"", i32 0} ... call void @llvm.dbg.stoppoint(i32 5, i32 5, metadata !1) store i32

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

Dear Staff, Here are some questions on the output formats of AliasSetTracker. The code is as below: int G1 = 9; int G2 = 5; int main() { int * XX; int * YY; XX = &G1; YY = XX; YY = &G2; XX = &G2; } The output for -anders-aa is: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea6fb0,0] may alias, Mod/Ref 10 Call Sites: void ({ }*)*

On Sat, 8 Apr 2006, Jim Laskey wrote: > If you look at the stoppoint calls you'll see that you can find the line > number and if you follow the compile unit argument on the call you will find > the file. The byte codes that follow the call would have been generated by > the code on that source line. I'd suggest an approach like this: Given an instruction in the a basic

Quoting Eli Friedman <eli.friedman at gmail.com>: Dear Eli, Thanks very much for your reply. I have modified the XX and YY to be global variables, but the output of AliasSetTracker are still MUST alias: Alias Set Tracker: 5 alias sets for 4 pointer values. AliasSet[0xea55d0,0] may alias, Mod/Ref 8 Call Sites: void ({ }*)* @llvm.dbg.func.start, void (i32, i32, { }*)*

I get it now, I can't believe I didn't understand that before. Thank you all for your help! - John On 4/8/06, Chris Lattner <sabre at nondot.org> wrote: > > On Sat, 8 Apr 2006, Jim Laskey wrote: > > If you look at the stoppoint calls you'll see that you can find the line > > number and if you follow the compile unit argument on the call you will > find >

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 Apr 5, 2009, at 11:54 PMPDT, vasudev wrote: > I need to generate line number debug information for PIC16 target. > PIC16 does not support dwarf format. It supports coff format. So I > need > to custom handle the STOPPOINT nodes. Without -fast option the > STOPPOINT > nodes are not created in dag because of the below check in > SelectionDAGBuild.cpp > if (Fast)

Hi, I would like to know how much effect these stoppoint calls have on the optimization of the bytecode? DOes insertion of debugging info cause opportunities for optimization (especially interprocedural dead code elimination and interprocedural constant propogation) to be reduced? The -g code is not very readable, so I am not able to confirm this by my own experiment. Thanks! Nikhil On Sat,

Thanks for the info regarding DebugLoc field. Another related question that I have is regarding debug info for local variables. With -fast option, ISD::DECLARE nodes are created in DAG for debug info of local variables. I am planning to custom handle these nodes, get the required info from llvm.dbg.variable global address and emit it in ISel. But without -fast option ISD::DECLARE nodes

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

On Apr 7, 2009, at 9:52 PMPDT, vasudev wrote: > Thanks for the info regarding DebugLoc field. Another related > question > that I have is regarding debug info for local variables. With -fast > option, ISD::DECLARE nodes are created in DAG for debug info of local > variables. I am planning to custom handle these nodes, get the > required > info from llvm.dbg.variable

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

I need to generate line number debug information for PIC16 target. PIC16 does not support dwarf format. It supports coff format. So I need to custom handle the STOPPOINT nodes. Without -fast option the STOPPOINT nodes are not created in dag because of the below check in SelectionDAGBuild.cpp if (Fast) DAG.setRoot(DAG.getDbgStopPoint(getRoot(), If I give -fast option then the Fast

I'm playing around with different combinations of LTO passes, and I've run into a strange problem: I have a 'main' function that looks like this: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* %args) { entry: call void @llvm.dbg.func.start(metadata !0) call void @llvm.dbg.stoppoint(i32 2, i32 19, metadata

On Sep 30, 2009, at 12:06 AM, Talin wrote: > I'm playing around with different combinations of LTO passes, and > I've run into a strange problem: > > I have a 'main' function that looks like this: > > define i32 @"main(tart.core.Array[tart.core.String])- > >int"(%"tart.core.Array[tart.core.String]"* %args) { > entry: > call

Well, after some investigation I have a few more clues as to what is going on. I have a module which contains a call to an external native function. This native function lives in a static library, and there is an external declaration for it in the module. I find that I can run "llvm-ld -disable-opts -native -l mylibrary test.bc" and it works fine. That is, llvm-ld is able to

Hi Devang, >> I use llvm and llvm-gcc as a C-to-C transformation tool using a >> modified version of the c backend, and rely on llvm debug instructions >> to link back to the original source code. >> >> Does anyone know how to get detailed line number and variable debug >> information at optimization levels beyond O0? >> >> Currently, I extract this

Sounds like LLVM thinks the calling conventions or declarations are mismatched. See: http://llvm.org/docs/FAQ.html#callconvwrong Reid On Sat, Oct 3, 2009 at 1:16 AM, Talin <viridia at gmail.com> wrote: > Well, after some investigation I have a few more clues as to what is > going on. > > I have a module which contains a call to an external native function. > This native

Hi, I'm just getting back to working on the cfe debug info after a brief hiatus. It appears that the appropriate place to be inserting stoppoints is starting in llvm_expand_stmt, using STMT_LINENO(t) . If that's not the best place, comments would be appreciated. Using the debug_hooks seems to be a non-starter, because they're called during rtl generation, which apparently isn't