search for: ipodbgopt

On Linux, when I run "make TEST=ipodbgopt" in MultiSource/Applications/sqlite3 I get: make[4]: Entering directory `/home/foad/llvm/poo/build/test-suite/MultiSource/Applications/sqlite3' Compiling shell.c to Output/shell.bc /home/foad/svn/llvm-project/test-suite/trunk/MultiSource/Applications/sqlite3/speedtest.tcl make[4]: execvp:...

On 2009-05-29 15:55, Jay Foad wrote: > On Linux, when I run "make TEST=ipodbgopt" in > MultiSource/Applications/sqlite3 I get: > > make[4]: Entering directory > `/home/foad/llvm/poo/build/test-suite/MultiSource/Applications/sqlite3' > Compiling shell.c to Output/shell.bc > /home/foad/svn/llvm-project/test-suite/trunk/MultiSource/Applications/sqlite3/s...

I see that llvm-gcc now has some support for generating debug info when optimising - thanks! However, it still doesn't generate debug info for global variables when optimising. Is there any reason for this? With the attached patch, the whole test suite passes for me with TEST=ipodbgopt. Thanks, Jay. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.globaldebug Type: application/octet-stream Size: 609 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090529/daa5888f/attachment.obj>

>> Doesn't the toplevel configure set TCLSH in Makefile.config? There seems to be a problem with reconfiguring LLVM when you use a config.cache file. In an empty directory I get: $ ~/svn/llvm-project/llvm/trunk/configure --cache-file=config.cache [... lots of stuff ...] $ grep -i tclsh Makefile.config TCLSH := /usr/bin/tclsh8.4 $ ~/svn/llvm-project/llvm/trunk/configure

> TEST=ipodbgopt currently runs through -strip-debug-declare immediately, > which would hide such cases.  Try it with that flag removed and I bet you'll > see some failures. Yes, thanks, I hadn't noticed the -strip-debug-declare. Incidentally I only "see" the failures because some "TE...

...that llvm-gcc now has some support for generating debug info > when optimising - thanks! > > However, it still doesn't generate debug info for global variables > when optimising. Is there any reason for this? With the attached > patch, the whole test suite passes for me with TEST=ipodbgopt. The reason is given in the comment your patch deletes. Having debug info affect the codegen is pretty bad, because you get situations where a bug goes away when you turn on debug info, and you can't debug it. TEST=ipodbgopt currently runs through -strip-debug-declare immediately, w...

...kill > optimization, don't they? We worked hard to avoid this. Now if a debug stop point threatens to kill optimization then the llvm optimizer will kill the debug stop point itself! We have updated optimizer in all cases we could find. (Try running nightly tester using TEST=dbgopt and TEST=ipodbgopt and report failures.) However this means, in optimized code you may lose location info here and there. > We have our own privately-maintained way of tracking line information even > in optimized code but it's a big hack and not something suitable for > pushing upstream. Would it be p...

On Thursday 09 July 2009 10:01, John Criswell wrote: > Dear All, > > To add to this, what you want to do is find the appropriate debug stop > point intrinsic and then use it to look up the information for that > instruction. Ick. So line number information is only available at debug stop points? That's bad when compiling optimized code since the debug stops kill optimization,

Dear All, To add to this, what you want to do is find the appropriate debug stop point intrinsic and then use it to look up the information for that instruction. Here is some sample code from SAFECode that finds the debug information associated with a CallInst (LLVM call instruction) held in the variable CI. It uses the findStopPoint() function in llvm/Analyis/DebugInfo.h: // // Get the