similar to: [LLVMdev] Source level debugging

Well, I am much happier now that I understand about dsymutil, and can actually step through my program in gdb. However, there are still some issues that are puzzling me. 1) First off, the debugger appears to stop at odd points. The IR for my main function looks correct to me: define i32 @"main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"*

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

Hi Martijn, On Tue, Nov 17, 2009 at 3:25 AM, Martijn <martijn at martijnrutten.com> wrote: >> >> Without mem2reg pass, you're unlikely to get much optimization done on your IR. > > Clear, thanks! I presume the mem2reg pass is also essential in the > CLang frontend, so CLang is not an alternative to llvm-gcc to keep > more debug information? Yes. > For the

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 ({ }*)*

Hi Martijn On Fri, Nov 13, 2009 at 4:52 AM, Martijn <martijn at martijnrutten.com> wrote: > Hello, > > 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

Hello, 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 debug information by compiling with -g. This works fine with

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, { }*)*

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

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

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

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

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

Problem 1: I tried llvm-db of LLVM 1.6, in the Linux environment. However, it always prompts the following info for different tests: ====================================== :> llvm-db a.out.bc llvm-db: The LLVM source-level debugger Loading program... successfully loaded 'a.out.bc'! (llvm-db) run Starting program: a.out.bc Error: Error waiting for the child process to stop. It exited

Hi, It's taking me a while to get familiar with the cfe in order to add emitting stop points for debugging. It's a lot to work through, so in order to speed things up, I've got a few questions. Any help would be appreciated. I understand the design of the intrinsics once they're in the code, but how to generate them is still a little fuzzy, mainly because llvm_expand is a little

Hello, Nicolas. > Is there a way in llvm to get the address of a generated instruction? Or > somehow to fix the location of a label in the llvm code (something that > may look like a basic block perhaps) and get after the compilation the > address of this label? Maybe it's worth to use llvm.dbg.stoppoint? -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

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

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

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