[LLVMbugs] [Bug 20907] Inlining corrupts debug locations if call-site's debug location is unknown

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=20907

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from David Blaikie <dblaikie at gmail.com> ---
(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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140915/c4100203/attachment.html>