http://llvm.org/bugs/show_bug.cgi?id=20907
David Blaikie <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #8 from David Blaikie <[email protected]> --- (In reply to comment #7) > (In reply to comment #6) > > That would be ideal - for you and for me. Once you add a debug location to > > the call site then you won't have to strip all the debug info out of the > > debug function that's called from the glue - and if the glue is inlined > > (along with the debug function already inlined into the glue) you should get > > an inlined scope for the inner debug function in the outer debug function - > > the glue will just be un-attributed instructions in the outer function. > > OK, we'll do that then. Great! > > > However, it would be nice to at least provide an earlier assertion in the > > > inlining pass that makes sure that this kind of thing doesn't occur. It > > > was > > > rather time-consuming to find out what the actual problem was. Just some > > > kind of hint that call-sites must have debug info if their call is inlined > > > and the inlined instructions *do* have debuginfo. > > > > Agreed - I debugged several of these issue & they were painful to varying > > degrees. > > > > You'll see that in the patch that was reverted, there's a change to the > > debug info verifier. This can be enabled (I forget how, exactly) in LLVM and > > run between each optimization pass - so it should diagnose the pass that > > violates the desired invariant (that any instruction in a debug-having > > function, has a scope chain that leads back to that function, not any other > > functioN) > > That sounds incredibly useful :) Yep - it should be accessible, I think, via "-mllvm -verify-debug-info" (you could try locally unreverting my patch and using those flags to see if they diagnose the problem you have) -- You are receiving this mail because: You are on the CC list for the bug.
_______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
