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 block, scan up and/or down the basic block, stopping at the first llvm.dbg.stoppoint instruction. Something like this should work: #include "llvm/IntrinsicInst.h" ... for (...) if (DbgStopPointInst *SP = dyn_cast<DbgStopPointInst>(Inst)) std::cerr << "Loc: " << SP->getFileName() << ":" << SP->getLine() << "\n"; If you look at IntrinsicInst, you'll see methods to get the filename,directory,line#,col#, all packaged up into an easy to use class (some of Jim's excellent work :). -Chris> On Apr 8, 2006, at 5:33 AM, John Trimble wrote: > >> 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 that finds bytecode instructions that >> represent indirect calls, now I want to find out what line number and >> source file that indirect call came from. Is there currently not a way to >> get this type of information? Thanks again. >> >> - John Trimble >> >> On 4/7/06, Reid Spencer <reid at x10sys.com> wrote: >> The debug intrinsics are intended for that. Please see: >> http://llvm.org/docs/SourceLevelDebugging.html >> for the details. >> >> Please note that this is being worked on actively Jim Laskey at Apple. >> He's working to get these intrinsics to generate DWARF output so that >> LLVM generated code can be used with a debugger. However, the intrinsics >> can be processed in whatever way you'd like via an LLVM pass. >> >> Reid. >> >> On Fri, 2006-04-07 at 14:59 -0700, John Trimble wrote: >> > So if compile some file test.c and get some binary test.bc can I >> > relate statements in test.bc with source code line numbers in test.c >> > and if so how would I go about doing that. Thanks for your time. >> > >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.2.7 (GNU/Linux) >> >> iD8DBQBENusl3J9yEj6nvGcRAnu4AJ47NLg1bWv7mmzfa5+Et9ktF4QaYQCfUGeN >> wpHV/Hj6NkQWvWIJRzdZO2c>> =NvMj >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-Chris -- http://nondot.org/sabre/ http://llvm.org/
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 > > 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 block, scan up and/or down the basic > block, stopping at the first llvm.dbg.stoppoint instruction. Something > like this should work: > > #include "llvm/IntrinsicInst.h" > ... > > for (...) > if (DbgStopPointInst *SP = dyn_cast<DbgStopPointInst>(Inst)) > std::cerr << "Loc: " << SP->getFileName() << ":" << SP->getLine() << > "\n"; > > If you look at IntrinsicInst, you'll see methods to get the > filename,directory,line#,col#, all packaged up into an easy to use class > (some of Jim's excellent work :). > > -Chris > > > On Apr 8, 2006, at 5:33 AM, John Trimble wrote: > > > >> 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 that finds bytecode instructions > that > >> represent indirect calls, now I want to find out what line number and > >> source file that indirect call came from. Is there currently not a way > to > >> get this type of information? Thanks again. > >> > >> - John Trimble > >> > >> On 4/7/06, Reid Spencer <reid at x10sys.com> wrote: > >> The debug intrinsics are intended for that. Please see: > >> http://llvm.org/docs/SourceLevelDebugging.html > >> for the details. > >> > >> Please note that this is being worked on actively Jim Laskey at Apple. > >> He's working to get these intrinsics to generate DWARF output so that > >> LLVM generated code can be used with a debugger. However, the > intrinsics > >> can be processed in whatever way you'd like via an LLVM pass. > >> > >> Reid. > >> > >> On Fri, 2006-04-07 at 14:59 -0700, John Trimble wrote: > >> > So if compile some file test.c and get some binary test.bc can I > >> > relate statements in test.bc with source code line numbers in test.c > >> > and if so how would I go about doing that. Thanks for your time. > >> > > >> > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.2.7 (GNU/Linux) > >> > >> iD8DBQBENusl3J9yEj6nvGcRAnu4AJ47NLg1bWv7mmzfa5+Et9ktF4QaYQCfUGeN > >> wpHV/Hj6NkQWvWIJRzdZO2c> >> =NvMj > >> -----END PGP SIGNATURE----- > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> > >> > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > -Chris > > -- > http://nondot.org/sabre/ > http://llvm.org/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20060408/2dba478a/attachment.html>
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, Apr 08, 2006 at 13:50 -0700, John Trimble wrote:> 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 > > > 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 block, scan up and/or down the basic > > block, stopping at the first llvm.dbg.stoppoint instruction. Something > > like this should work: > > > > #include "llvm/IntrinsicInst.h" > > ... > > > > for (...) > > if (DbgStopPointInst *SP = dyn_cast<DbgStopPointInst>(Inst)) > > std::cerr << "Loc: " << SP->getFileName() << ":" << SP->getLine() << > > "\n"; > > > > If you look at IntrinsicInst, you'll see methods to get the > > filename,directory,line#,col#, all packaged up into an easy to use class > > (some of Jim's excellent work :). > > > > -Chris > > > > > On Apr 8, 2006, at 5:33 AM, John Trimble wrote: > > > > > >> 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 that finds bytecode instructions > > that > > >> represent indirect calls, now I want to find out what line number and > > >> source file that indirect call came from. Is there currently not a way > > to > > >> get this type of information? Thanks again. > > >> > > >> - John Trimble > > >> > > >> On 4/7/06, Reid Spencer <reid at x10sys.com> wrote: > > >> The debug intrinsics are intended for that. Please see: > > >> http://llvm.org/docs/SourceLevelDebugging.html > > >> for the details. > > >> > > >> Please note that this is being worked on actively Jim Laskey at Apple. > > >> He's working to get these intrinsics to generate DWARF output so that > > >> LLVM generated code can be used with a debugger. However, the > > intrinsics > > >> can be processed in whatever way you'd like via an LLVM pass. > > >> > > >> Reid. > > >> > > >> On Fri, 2006-04-07 at 14:59 -0700, John Trimble wrote: > > >> > So if compile some file test.c and get some binary test.bc can I > > >> > relate statements in test.bc with source code line numbers in test.c > > >> > and if so how would I go about doing that. Thanks for your time. > > >> > > > >> > > >> > > >> -----BEGIN PGP SIGNATURE----- > > >> Version: GnuPG v1.2.7 (GNU/Linux) > > >> > > >> iD8DBQBENusl3J9yEj6nvGcRAnu4AJ47NLg1bWv7mmzfa5+Et9ktF4QaYQCfUGeN > > >> wpHV/Hj6NkQWvWIJRzdZO2c> > >> =NvMj > > >> -----END PGP SIGNATURE----- > > >> > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >> > > >> > > >> > > >> _______________________________________________ > > >> LLVM Developers mailing list > > >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > > > > > > > -Chris > > > > -- > > http://nondot.org/sabre/ > > http://llvm.org/ > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >> _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-- One short sleep past, we wake eternally...