summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2014-06-01 03:38:13 +0000
committerDavid Blaikie <dblaikie@gmail.com>2014-06-01 03:38:13 +0000
commit0d9056d7660a6fecfdd704395e7f629e4f65c11c (patch)
treeb92298241824185816a5835271746a7d649f5363 /lib
parent4a0555250d85f2da6f26881ae9c15bcdb49b1d98 (diff)
downloadllvm-0d9056d7660a6fecfdd704395e7f629e4f65c11c.tar.gz
llvm-0d9056d7660a6fecfdd704395e7f629e4f65c11c.tar.bz2
llvm-0d9056d7660a6fecfdd704395e7f629e4f65c11c.tar.xz
DebugInfo: Assert that DbgVariables have associated DIEs
This was previously committed in r209680 and reverted in r209683 after it caused sanitizer builds to crash. The issue seems to be that the DebugLoc associated with dbg.value IR intrinsics isn't necessarily accurate. Instead, we duplicate the DIVariables and add an InlinedAt field to them to record their location. We were using this InlinedAt field to compute the LexicalScope for the variable, but not using it in the abstract DbgVariable construction and mapping. This resulted in a formal parameter to the current concrete function, correctly having no InlinedAt information, but incorrectly having a DebugLoc that described an inlined location within the function... thus an abstract DbgVariable was created for the variable, but its DIE was never constructed (since the LexicalScope had no such variable). This DbgVariable was silently ignored (by testing for a non-null DIE on the abstract DbgVariable). So, fix this by using the right scoping information when constructing abstract DbgVariables. In the long run, I suspect we want to undo the work that added this second kind of location tracking and fix the places where the DebugLoc propagation on the dbg.value intrinsic fails. This will shrink debug info (by not duplicating DIVariables), make it more efficient (by not having to construct new DIVariable metadata nodes to try to map back to a single variable), and benefit all instructions. But perhaps there are insurmountable issues with DebugLoc quality that I'm unaware of... I just don't know how we can't /just keep the DebugLoc from the dbg.declare to the dbg.values and never get this wrong/. Some history context: http://llvm.org/viewvc/llvm-project?view=revision&revision=135629 http://llvm.org/viewvc/llvm-project?view=revision&revision=137253 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209984 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib')
-rw-r--r--lib/CodeGen/AsmPrinter/DwarfDebug.cpp2
-rw-r--r--lib/CodeGen/AsmPrinter/DwarfUnit.cpp3
2 files changed, 2 insertions, 3 deletions
diff --git a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
index b2ae9ad36d..73496b0c38 100644
--- a/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
+++ b/lib/CodeGen/AsmPrinter/DwarfDebug.cpp
@@ -1175,7 +1175,7 @@ DwarfDebug::collectVariableInfo(SmallPtrSet<const MDNode *, 16> &Processed) {
Processed.insert(DV);
const MachineInstr *MInsn = Ranges.front().first;
assert(MInsn->isDebugValue() && "History must begin with debug value");
- DbgVariable *AbsVar = findAbstractVariable(DV, MInsn->getDebugLoc());
+ DbgVariable *AbsVar = findAbstractVariable(DV, Scope->getScopeNode());
DbgVariable *RegVar = new DbgVariable(MInsn, AbsVar, this);
if (!addCurrentFnArgument(RegVar, Scope))
addScopeVariable(Scope, RegVar);
diff --git a/lib/CodeGen/AsmPrinter/DwarfUnit.cpp b/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
index 29ebad4025..fddc7fa137 100644
--- a/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
+++ b/lib/CodeGen/AsmPrinter/DwarfUnit.cpp
@@ -1781,8 +1781,7 @@ std::unique_ptr<DIE> DwarfUnit::constructVariableDIEImpl(const DbgVariable &DV,
// Define variable debug information entry.
auto VariableDie = make_unique<DIE>(DV.getTag());
- DbgVariable *AbsVar = DV.getAbstractVariable();
- if (AbsVar && AbsVar->getDIE())
+ if (DbgVariable *AbsVar = DV.getAbstractVariable())
addDIEEntry(*VariableDie, dwarf::DW_AT_abstract_origin, *AbsVar->getDIE());
else {
if (!Name.empty())