similar to: [LLVMdev] llvm dwarf debug info for locals with llvm.dbg.define

On Jul 27, 2012, at 2:35 AM, Carlo Kok <ck at remobjects.com> wrote: > 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 >

Hi Duncan, But in the doc "Source Level Debugging with LLVM", it shows that llvm 2.6 could get column number. There's an example in the doc as following: http://llvm.org/docs/SourceLevelDebugging.html 1. void foo() { 2. int X = 21; 3. int Y = 22; 4. { 5. int Z = 23; 6. Z = X; 7. } 8. X = Y; 9. } Compiled to LLVM, this function would be represented

I'm running into a problem with generating debugging information that I'm not sure how to debug; I'd be happy to have some suggestions about where to start digging in. In short, I believe that I'm correctly generating debug info (with DIBuilder, which has so far been quite nice!), and a scan of the meta-data in the IR looks generally right. However, if I run dwarfdump on my

On Apr 29, 2011, at 5:49 PM, Matt Pharr wrote: > I'm running into a problem with generating debugging information that I'm not sure how to debug; I'd be happy to have some suggestions about where to start digging in. > > In short, I believe that I'm correctly generating debug info (with DIBuilder, which has so far been quite nice!), and a scan of the meta-data in the IR

On Wed, Jul 14, 2010 at 3:03 PM, Arvind Sudarsanam <arvind.sudarsanam at aggiemail.usu.edu> wrote: > Dear all, > > I have the following source code: > > long f(long x, long y) > { >        long u; > >   u = x+y; >   return u; > }; > > After clang (with debug option set) and llvm opt using mem2reg, I get > the following .ll file >

Hi Devang, Thanks for your reply. You mentioned " First parameter is the compiler generated temp. and 3rd parameter provides info about the variable, including its name 'u'." I did manage to get this far. But, I am finding it difficult to access this info using LLVM APIs. The third parameter is of type "metadata". So I was able to access it by casting it to MDNode.

Dear all, I have the following source code: long f(long x, long y) { long u; u = x+y; return u; }; After clang (with debug option set) and llvm opt using mem2reg, I get the following .ll file *************************************************************************** ; ModuleID = '<stdin>' target datalayout =

I found the problem. The llvm.dbg.declare call must have a !dbg tag, otherwise the location info is not generated. Changing the invocation in my original example to "call void @llvm.dbg.declare(metadata !{i32* %"bar:Int32"}, metadata !13), !dbg !16" causes MC to generate the local location as expected. -Joe On Thu, Dec 29, 2011 at 12:41 PM, Joe Groff <arcata at

I figured out my previous problem with DIBuilder. However, now I can't seem to get the compiler to emit location information for local variables. Here's how my IR looks: --- define i32 @"\01_main"() { init: %exception1 = alloca i8* %0 = alloca i32 %"bar:Int32" = alloca i32 %1 = alloca i32 %2 = alloca i32* br label %code code:

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

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

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 =

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

I was told that my writeup lacked an example and details so I reproduced the code that X uses and I was able to boil down the issue to a couple of lines of code. Sorry again for the length of this email. Code was compiled on OpenBSD with clang 3.0-release. ======================================================================== With -O0 which works as X expects:

Eli, Thanks very much for your reply. That's what I want to know. It works for this example. But I usually have to deal with the optimized bytecode with "-O". See the example: ************** C source ************** int h (int j, int i) { int tmp; tmp = j+i+2; return tmp; } +++++++++++++++++++++++++++++++++++++ .ll file: ; ModuleID = 'simplecase.c' target

I need read a table in a string with special format. I used read.csv and textConnection function. But i am confuse about textConnection by follow code. case A: It is OK£¡ str0 <- '{"abc",{"def","X,1&Y,2&Z,3"}}' str1 <- strsplit(str0,'"')[[1]][6] str2 <- gsub("&","\n", str1) con <-

Hi, I know that if i want to see the SPLUS or R-source code of a function,i should give the command without the brackets.For example:  rsquared.lmRobMM function(x) {  str0 <- "Initial S-estimate"  str1 <- "Final M-estimate"  if(x$est == "final") {   z <- x$r.squared   attr(z, "info") <- str1  }  if(x$est == "initial") {   z <-

Hi, I want to get the mapping between C source's variables and bytecode variables. It seems that llvm doesn't provide this mapping, so I think a walk-around method is to get the instruction's mapping. I have to use llvm-gcc, not clang. Any advice? Thanks. Best, Kecheng 2010-05-13 From: Eli Friedman Date: 2010-05-13 15:38:36 To: Kecheng Cc: llvmdev Subject: Re: [LLVMdev] How

Hi, I want to know the variable mapping between the source and llvm bytecode. It seems that current llvm debugging information cannot provide this mapping directly. Here is my examples (llvm 2.7). In this exmaple, I want to know the mapping: tmp<--->%4. But current llvm's debugging information can only provide that the instruction "%4 = add nsw i32 %3, 2" is at line 3 in

Hi all, I'm using clang + LLVM 2.9. Let's consider following code sample: extern void bar(int x) ; void foo(int y) { bar(y) ; } When compiled with clang at -O2 -g I've got following LLVM file: ; ModuleID = 'localvar.c' target datalayout =