similar to: [LLVMdev] [PROPOSAL] Attach debugging information with LLVM instruction

On Sep 10, 2009, at 10:48 AM, Devang Patel wrote: > Hi All, > > Today, debugging information is encoded in LLVM IR using various > llvm.dbg intrinsics, such as llvm.dbg.stoppoint. For exmaple, Right. > This approach has several disadvantages. > - The llvm.dbg.stoppoint()s act like hurdles to the optimizer. The > LLVM customers expect that the optimizer does not trip over

On 2009-09-10 20:48, Devang Patel wrote: > Now, the optimizer does not need to worry about those llvm.dbg > hurdles. Instructions do not lose their location information when they > are rearranged in instruction stream. And the stage is set to produce, > preserve and emit accurate debug information for inlined functions. > > Any thoughts/suggestions/questions ? > Sounds

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

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]"*

On Sep 10, 2009, at 10:48 AM, Devang Patel wrote: > The proposed solution is to optionally attach debug information with > llvm instruction directly. A new keyword 'dbg' is used to identify > debugging information associated with an instruction. The debugging > information, if available, is printed after the last instruction > operand. The debugging information entry uses

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

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

On 2008-11-03 12:33, Chris Lattner wrote: > On Oct 31, 2008, at 1:29 PM, Török Edwin wrote: > >> Hi Dan, >> I am actually more interested in Analysis working in presence of debug >> info, but in order to get any meaningful results, you need to run some >> transformations, at least GVN, otherwise loops aren't transformed to >> canonical form either.

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

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

[Moving discussion to LLVMdev] On 2008-10-31 21:55, Dan Gohman wrote: > Hi Török, > > @llvm.dbg.stoppoint actually does read and write memory, in a > sense. It's a point where a user could stop in a debugger, and > use the debugger to both read and write memory. If the optimizers > are allowed to reorder or delete memory operations, these > intrinsics will become

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, Im new to llvm and I'm using llvm-2.6 and I know how to extract the metadata in the stoppoints but what I'm interested in is the meta data regarding a local variable. I know that the @llvm.dgb.declare such as: call void @llvm.dbg.declare({ }* %2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable9 to { }*)) links to meta data for @llvm.dbg.variable9 which is:

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

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

On Oct 31, 2008, at 1:29 PM, Török Edwin wrote: > Hi Dan, > I am actually more interested in Analysis working in presence of debug > info, but in order to get any meaningful results, you need to run some > transformations, at least GVN, otherwise loops aren't transformed to > canonical form either. Right. > So we could: > - teach GVN that a dependency on a debug

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