similar to: [LLVMdev] Using debug info in static analysis

On Dec 25, 2007, at 5:56 AM, Török Edwin wrote: > I was looking at how to use debug info to find out original > source:line > for a certain function/variable in the llvm bytecode. > > I read http://llvm.org/docs/SourceLevelDebugging.html, and then I have > looked in lib/Debugger/ProgramInfo.cpp. > getFunction() looks useful, however I am not sure how to call it. I >

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

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 >

John, 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. -- Jim On Apr 8, 2006, at 5:33 AM, John Trimble wrote: > Thanks for your help. I took a look at http://llvm.org/docs/

Thanks for your help. I took a look at http://llvm.org/docs/SourceLevelDebugging.html and it seems like this doesn't give you much in the way of line number information. If you know what source line you are interested in then you can set a breakpoint, but suppose you want to know the line number in the source code for some arbitrary bytecode instruction. In my particular case, I have a pass

LLVM build without big problems in obj dir == src dir case (for example, last night tester build) But I have problem with building CVS version LLVM in obj dir != src dir case. ======= Finished building ModuleMaker debug executable (without symbols) ======= gmake[2]: Leaving directory `/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker' gmake[1]: Leaving directory

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,

I resend email with updated (after mass header move) log examples. > LLVM build without big problems in obj dir == src dir case (for example, > last night tester build) > But I have problem with building CVS version LLVM in obj dir != src dir > case. > gmake[1]: Entering directory `/usr/home/wanderer/pkg/build/llvm/obj/projects' gmake[2]: Entering directory

I don't think it's the same problem as you described. By printing I meant calling printf function and passing my global variable as one of the arguments. My code: Instruction* InstructionVisitor::incrementGlobalKey(Instruction* I) { IRBuilder<> Builder(I->getContext()); Builder.SetInsertPoint(I->getNextNode()); GlobalVariable* key =

Hi Everyone, I'm quite new to LLVM and I want to update value of global variable in LLVM IR. I created new global variable in ModulePass: bool runOnModule(llvm::Module &M) { IRBuilder<> Builder(M.getContext()); Instruction *I = &*inst_begin(M.getFunction("main")); Builder.SetInsertPoint(I); M.getOrInsertGlobal("globalKey",

[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

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

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

Hi, Well, yes i did try your suggestion but i keep on running into a compilation problem. The error is: llvm[0]: Compiling Hello.cpp for Release build (PIC) /home/saraswat/llvm/llvm-2.1/include/llvm/ADT/GraphTraits.h: In instantiation of `llvm::GraphTraits<llvm::ilist_iterator<llvm::BasicBlock> >': Hello.cpp:59: instantiated from here

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 want to know How to count the number of predecessors for each basic block? Thank You ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

Hi aditya, There are two ways to cound the number of predecessors for each basic block. You can generate the control flow graph using the CallGraphScc pass with the granularity of basic block and can simply traverse the graph bottom up till the root. The number of nodes encountered would be the number of predecessors. The second way would be to use the special ;preds marker in the llvm IR. Each

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.

Hi all, Is there a way to walk through ALL the predecessors of a basic block in a CFG. I tried to iterate over the preds using this method for (pred_iterator PI = pred_begin(BB), E = pred_end(BB); PI != E; ++I) { BasicBlock *PredBB = *PI; } but this only gives the immediate predecessors for a basic block. For example, in this sample control flow graph. entry -> bb1 -> bb2 -> bb4

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