[LLVMbugs] [Bug 15405] Debug information not being generated

[bugzilla-daemon at llvm.org]

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

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #12 from David Blaikie <dblaikie at gmail.com> ---
(In reply to comment #11)
> I have not been able to find the time to run this on the gdb test suite.
> 
> However, Dave's fix led me to realise that debug information was
> deliberately being suppressed because it would be unnecessary: in this case
> the debug information for the call instruction in question is guaranteed to
> be the same as for the preceding instruction.
> 
> It seems then that it would be better for me to adapt my tool on top of
> CLANG to deal with this scenario rather than fixing the issue (which appears
> to be a design decision, not a bug) in CLANG.
> 
> If you agree then please go ahead and close the bug.
> 
> Thanks for your help!
> 
> Ally

Coming back to this, I'm not sure I agree that this is the right thing for
clang to do - the code in question breaks inlining which doesn't walk backwards
from the call instruction looking for the last IR instruction to include a
DebugLoc. Inlining just uses the debugloc of the call instruction - if it has
none, but the calling function does, and the caller does have debug info, just
no debugloc on this specific call instruction, bad things happen... the
debugloc doesn't get wired up appropriately.

I'm looking at fixing this one way or another - either removing these hacks
(they might not be relevant anymore anyway - the DebugLoc encoding is now
fairly efficient/low-cost, I believe, perhaps it wasn't when this hack was
added?) or figuring out where to re-enable location information once we're
passed the unconditional jump that these hacks were intended to skip debugloc
for (but before we emit any more function calls/user-implied code)

-- 
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/20140616/b846940d/attachment.html>