[LLVMbugs] [Bug 20907] New: Inlining corrupts debug locations if call-site's debug location is unknown
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Thu Sep 11 08:27:56 PDT 2014
http://llvm.org/bugs/show_bug.cgi?id=20907
Bug ID: 20907
Summary: Inlining corrupts debug locations if call-site's debug
location is unknown
Product: libraries
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: DebugInfo
Assignee: unassignedbugs at nondot.org
Reporter: michaelwoerister at posteo.net
CC: llvmbugs at cs.uiuc.edu
Classification: Unclassified
In the Rust compiler we have consistently run into an assertion in
LexicalScopes::getOrCreateRegularScope() at:
assert(DISubprogram(Scope).describes(MF->getFunction()));
This would only occur when function inlining was activated. After debugging
into this, it turns out the inlining pass leaves the debug source location info
in a state the is not properly handled by the LexicalScopes class:
The fixupLineNumbers() function in lib/Transforms/Utils/InlineFunction.cpp will
not modify debug locations *at all* if the source location of the call-site is
unknown. Because of this the instructions copied from the callee into the
caller are still associated to the callee source location, but without having
the additional InlinedAt data. The LexicalScopes class will then not know that
this is actually valid code it is dealing with.
As a quick fix, I modified the fixupLineNumbers() function to clear all debug
location information from inlined instructions if the call-site has no debug
location info attached. This solved the problem but is a bit of a crude
solution. I'm sure you people can come up with something better!
--
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/20140911/774546d5/attachment.html>
More information about the llvm-bugs
mailing list