2016-02-11 04:55:49 +08:00
|
|
|
//===-- llvm/lib/CodeGen/AsmPrinter/DebugHandlerBase.cpp -------*- C++ -*--===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2016-02-11 04:55:49 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Common functionality for different debug information format backends.
|
2018-12-01 00:54:43 +08:00
|
|
|
// LLVM currently supports DWARF and CodeView.
|
2016-02-11 04:55:49 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2018-12-19 07:10:17 +08:00
|
|
|
#include "llvm/CodeGen/DebugHandlerBase.h"
|
2017-08-31 01:50:21 +08:00
|
|
|
#include "llvm/ADT/Optional.h"
|
|
|
|
#include "llvm/ADT/Twine.h"
|
2016-02-11 04:55:49 +08:00
|
|
|
#include "llvm/CodeGen/AsmPrinter.h"
|
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
|
|
|
#include "llvm/CodeGen/MachineInstr.h"
|
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
2017-11-17 09:07:10 +08:00
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2016-04-15 02:29:59 +08:00
|
|
|
#include "llvm/IR/DebugInfo.h"
|
2016-08-27 01:58:37 +08:00
|
|
|
#include "llvm/MC/MCStreamer.h"
|
2020-07-22 16:25:14 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2016-02-11 04:55:49 +08:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2018-06-02 06:33:15 +08:00
|
|
|
#define DEBUG_TYPE "dwarfdebug"
|
|
|
|
|
2020-07-22 16:25:14 +08:00
|
|
|
/// If true, we drop variable location ranges which exist entirely outside the
|
|
|
|
/// variable's lexical scope instruction ranges.
|
|
|
|
static cl::opt<bool> TrimVarLocs("trim-var-locs", cl::Hidden, cl::init(true));
|
|
|
|
|
2017-08-31 01:50:21 +08:00
|
|
|
Optional<DbgVariableLocation>
|
|
|
|
DbgVariableLocation::extractFromMachineInstruction(
|
|
|
|
const MachineInstr &Instruction) {
|
|
|
|
DbgVariableLocation Location;
|
2021-03-10 22:35:55 +08:00
|
|
|
// Variables calculated from multiple locations can't be represented here.
|
|
|
|
if (Instruction.getNumDebugOperands() != 1)
|
2017-08-31 01:50:21 +08:00
|
|
|
return None;
|
2020-06-22 23:01:12 +08:00
|
|
|
if (!Instruction.getDebugOperand(0).isReg())
|
2017-08-31 01:50:21 +08:00
|
|
|
return None;
|
2020-06-22 23:01:12 +08:00
|
|
|
Location.Register = Instruction.getDebugOperand(0).getReg();
|
2017-08-30 04:59:25 +08:00
|
|
|
Location.FragmentInfo.reset();
|
|
|
|
// We only handle expressions generated by DIExpression::appendOffset,
|
|
|
|
// which doesn't require a full stack machine.
|
|
|
|
int64_t Offset = 0;
|
|
|
|
const DIExpression *DIExpr = Instruction.getDebugExpression();
|
|
|
|
auto Op = DIExpr->expr_op_begin();
|
2021-03-10 22:35:55 +08:00
|
|
|
// We can handle a DBG_VALUE_LIST iff it has exactly one location operand that
|
|
|
|
// appears exactly once at the start of the expression.
|
|
|
|
if (Instruction.isDebugValueList()) {
|
|
|
|
if (Instruction.getNumDebugOperands() == 1 &&
|
|
|
|
Op->getOp() == dwarf::DW_OP_LLVM_arg)
|
|
|
|
++Op;
|
|
|
|
else
|
|
|
|
return None;
|
|
|
|
}
|
2017-08-30 04:59:25 +08:00
|
|
|
while (Op != DIExpr->expr_op_end()) {
|
|
|
|
switch (Op->getOp()) {
|
|
|
|
case dwarf::DW_OP_constu: {
|
|
|
|
int Value = Op->getArg(0);
|
|
|
|
++Op;
|
|
|
|
if (Op != DIExpr->expr_op_end()) {
|
|
|
|
switch (Op->getOp()) {
|
|
|
|
case dwarf::DW_OP_minus:
|
|
|
|
Offset -= Value;
|
|
|
|
break;
|
|
|
|
case dwarf::DW_OP_plus:
|
|
|
|
Offset += Value;
|
2017-08-30 06:54:31 +08:00
|
|
|
break;
|
2017-08-30 04:59:25 +08:00
|
|
|
default:
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} break;
|
|
|
|
case dwarf::DW_OP_plus_uconst:
|
|
|
|
Offset += Op->getArg(0);
|
|
|
|
break;
|
|
|
|
case dwarf::DW_OP_LLVM_fragment:
|
|
|
|
Location.FragmentInfo = {Op->getArg(1), Op->getArg(0)};
|
|
|
|
break;
|
|
|
|
case dwarf::DW_OP_deref:
|
2017-08-31 23:56:49 +08:00
|
|
|
Location.LoadChain.push_back(Offset);
|
|
|
|
Offset = 0;
|
2017-08-30 04:59:25 +08:00
|
|
|
break;
|
|
|
|
default:
|
2017-08-31 01:50:21 +08:00
|
|
|
return None;
|
2017-08-30 04:59:25 +08:00
|
|
|
}
|
|
|
|
++Op;
|
|
|
|
}
|
|
|
|
|
2017-08-31 23:56:49 +08:00
|
|
|
// Do one final implicit DW_OP_deref if this was an indirect DBG_VALUE
|
|
|
|
// instruction.
|
|
|
|
// FIXME: Replace these with DIExpression.
|
|
|
|
if (Instruction.isIndirectDebugValue())
|
|
|
|
Location.LoadChain.push_back(Offset);
|
|
|
|
|
2017-08-31 01:50:21 +08:00
|
|
|
return Location;
|
2017-08-30 04:59:25 +08:00
|
|
|
}
|
|
|
|
|
2016-02-11 04:55:49 +08:00
|
|
|
DebugHandlerBase::DebugHandlerBase(AsmPrinter *A) : Asm(A), MMI(Asm->MMI) {}
|
|
|
|
|
2020-11-03 21:54:51 +08:00
|
|
|
void DebugHandlerBase::beginModule(Module *M) {
|
|
|
|
if (M->debug_compile_units().empty())
|
|
|
|
Asm = nullptr;
|
|
|
|
}
|
|
|
|
|
2016-02-11 04:55:49 +08:00
|
|
|
// Each LexicalScope has first instruction and last instruction to mark
|
|
|
|
// beginning and end of a scope respectively. Create an inverse map that list
|
|
|
|
// scopes starts (and ends) with an instruction. One instruction may start (or
|
|
|
|
// end) multiple scopes. Ignore scopes that are not reachable.
|
|
|
|
void DebugHandlerBase::identifyScopeMarkers() {
|
|
|
|
SmallVector<LexicalScope *, 4> WorkList;
|
|
|
|
WorkList.push_back(LScopes.getCurrentFunctionScope());
|
|
|
|
while (!WorkList.empty()) {
|
|
|
|
LexicalScope *S = WorkList.pop_back_val();
|
|
|
|
|
|
|
|
const SmallVectorImpl<LexicalScope *> &Children = S->getChildren();
|
|
|
|
if (!Children.empty())
|
|
|
|
WorkList.append(Children.begin(), Children.end());
|
|
|
|
|
|
|
|
if (S->isAbstractScope())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (const InsnRange &R : S->getRanges()) {
|
|
|
|
assert(R.first && "InsnRange does not have first instruction!");
|
|
|
|
assert(R.second && "InsnRange does not have second instruction!");
|
|
|
|
requestLabelBeforeInsn(R.first);
|
|
|
|
requestLabelAfterInsn(R.second);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return Label preceding the instruction.
|
|
|
|
MCSymbol *DebugHandlerBase::getLabelBeforeInsn(const MachineInstr *MI) {
|
|
|
|
MCSymbol *Label = LabelsBeforeInsn.lookup(MI);
|
|
|
|
assert(Label && "Didn't insert label before instruction");
|
|
|
|
return Label;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Return Label immediately following the instruction.
|
|
|
|
MCSymbol *DebugHandlerBase::getLabelAfterInsn(const MachineInstr *MI) {
|
|
|
|
return LabelsAfterInsn.lookup(MI);
|
|
|
|
}
|
|
|
|
|
2016-07-12 20:06:34 +08:00
|
|
|
/// If this type is derived from a base type then return base type size.
|
2019-05-07 10:06:37 +08:00
|
|
|
uint64_t DebugHandlerBase::getBaseTypeSize(const DIType *Ty) {
|
2016-07-12 20:06:34 +08:00
|
|
|
assert(Ty);
|
2019-05-07 10:06:37 +08:00
|
|
|
const DIDerivedType *DDTy = dyn_cast<DIDerivedType>(Ty);
|
2016-07-12 20:06:34 +08:00
|
|
|
if (!DDTy)
|
|
|
|
return Ty->getSizeInBits();
|
|
|
|
|
|
|
|
unsigned Tag = DDTy->getTag();
|
|
|
|
|
|
|
|
if (Tag != dwarf::DW_TAG_member && Tag != dwarf::DW_TAG_typedef &&
|
|
|
|
Tag != dwarf::DW_TAG_const_type && Tag != dwarf::DW_TAG_volatile_type &&
|
2022-01-06 02:48:41 +08:00
|
|
|
Tag != dwarf::DW_TAG_restrict_type && Tag != dwarf::DW_TAG_atomic_type &&
|
|
|
|
Tag != dwarf::DW_TAG_immutable_type)
|
2016-07-12 20:06:34 +08:00
|
|
|
return DDTy->getSizeInBits();
|
|
|
|
|
2019-05-07 10:06:37 +08:00
|
|
|
DIType *BaseType = DDTy->getBaseType();
|
2016-07-12 20:06:34 +08:00
|
|
|
|
2018-01-06 07:01:04 +08:00
|
|
|
if (!BaseType)
|
|
|
|
return 0;
|
2016-07-12 20:06:34 +08:00
|
|
|
|
|
|
|
// If this is a derived type, go ahead and get the base type, unless it's a
|
|
|
|
// reference then it's just the size of the field. Pointer types have no need
|
|
|
|
// of this since they're a different type of qualification on the type.
|
|
|
|
if (BaseType->getTag() == dwarf::DW_TAG_reference_type ||
|
|
|
|
BaseType->getTag() == dwarf::DW_TAG_rvalue_reference_type)
|
|
|
|
return Ty->getSizeInBits();
|
|
|
|
|
|
|
|
return getBaseTypeSize(BaseType);
|
|
|
|
}
|
|
|
|
|
2020-10-28 02:35:57 +08:00
|
|
|
bool DebugHandlerBase::isUnsignedDIType(const DIType *Ty) {
|
2021-04-12 11:13:17 +08:00
|
|
|
if (isa<DIStringType>(Ty)) {
|
2021-08-31 03:05:24 +08:00
|
|
|
// Some transformations (e.g. instcombine) may decide to turn a Fortran
|
|
|
|
// character object into an integer, and later ones (e.g. SROA) may
|
|
|
|
// further inject a constant integer in a llvm.dbg.value call to track
|
|
|
|
// the object's value. Here we trust the transformations are doing the
|
|
|
|
// right thing, and treat the constant as unsigned to preserve that value
|
|
|
|
// (i.e. avoid sign extension).
|
2021-04-12 11:13:17 +08:00
|
|
|
return true;
|
|
|
|
}
|
2021-08-31 03:05:24 +08:00
|
|
|
|
2020-10-28 02:35:57 +08:00
|
|
|
if (auto *CTy = dyn_cast<DICompositeType>(Ty)) {
|
2021-09-20 12:03:20 +08:00
|
|
|
if (CTy->getTag() == dwarf::DW_TAG_enumeration_type) {
|
|
|
|
if (!(Ty = CTy->getBaseType()))
|
|
|
|
// FIXME: Enums without a fixed underlying type have unknown signedness
|
|
|
|
// here, leading to incorrectly emitted constants.
|
|
|
|
return false;
|
|
|
|
} else
|
|
|
|
// (Pieces of) aggregate types that get hacked apart by SROA may be
|
|
|
|
// represented by a constant. Encode them as unsigned bytes.
|
|
|
|
return true;
|
2020-10-28 02:35:57 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (auto *DTy = dyn_cast<DIDerivedType>(Ty)) {
|
|
|
|
dwarf::Tag T = (dwarf::Tag)Ty->getTag();
|
|
|
|
// Encode pointer constants as unsigned bytes. This is used at least for
|
|
|
|
// null pointer constant emission.
|
|
|
|
// FIXME: reference and rvalue_reference /probably/ shouldn't be allowed
|
|
|
|
// here, but accept them for now due to a bug in SROA producing bogus
|
|
|
|
// dbg.values.
|
|
|
|
if (T == dwarf::DW_TAG_pointer_type ||
|
|
|
|
T == dwarf::DW_TAG_ptr_to_member_type ||
|
|
|
|
T == dwarf::DW_TAG_reference_type ||
|
|
|
|
T == dwarf::DW_TAG_rvalue_reference_type)
|
|
|
|
return true;
|
|
|
|
assert(T == dwarf::DW_TAG_typedef || T == dwarf::DW_TAG_const_type ||
|
|
|
|
T == dwarf::DW_TAG_volatile_type ||
|
2022-01-06 02:48:41 +08:00
|
|
|
T == dwarf::DW_TAG_restrict_type || T == dwarf::DW_TAG_atomic_type ||
|
|
|
|
T == dwarf::DW_TAG_immutable_type);
|
2020-10-28 02:35:57 +08:00
|
|
|
assert(DTy->getBaseType() && "Expected valid base type");
|
|
|
|
return isUnsignedDIType(DTy->getBaseType());
|
|
|
|
}
|
|
|
|
|
|
|
|
auto *BTy = cast<DIBasicType>(Ty);
|
|
|
|
unsigned Encoding = BTy->getEncoding();
|
|
|
|
assert((Encoding == dwarf::DW_ATE_unsigned ||
|
|
|
|
Encoding == dwarf::DW_ATE_unsigned_char ||
|
|
|
|
Encoding == dwarf::DW_ATE_signed ||
|
|
|
|
Encoding == dwarf::DW_ATE_signed_char ||
|
|
|
|
Encoding == dwarf::DW_ATE_float || Encoding == dwarf::DW_ATE_UTF ||
|
|
|
|
Encoding == dwarf::DW_ATE_boolean ||
|
|
|
|
(Ty->getTag() == dwarf::DW_TAG_unspecified_type &&
|
|
|
|
Ty->getName() == "decltype(nullptr)")) &&
|
|
|
|
"Unsupported encoding");
|
|
|
|
return Encoding == dwarf::DW_ATE_unsigned ||
|
|
|
|
Encoding == dwarf::DW_ATE_unsigned_char ||
|
|
|
|
Encoding == dwarf::DW_ATE_UTF || Encoding == dwarf::DW_ATE_boolean ||
|
|
|
|
Ty->getTag() == dwarf::DW_TAG_unspecified_type;
|
|
|
|
}
|
|
|
|
|
2017-05-27 04:09:00 +08:00
|
|
|
static bool hasDebugInfo(const MachineModuleInfo *MMI,
|
|
|
|
const MachineFunction *MF) {
|
2017-02-17 02:48:33 +08:00
|
|
|
if (!MMI->hasDebugInfo())
|
|
|
|
return false;
|
2017-12-16 06:22:58 +08:00
|
|
|
auto *SP = MF->getFunction().getSubprogram();
|
2017-02-17 02:48:33 +08:00
|
|
|
if (!SP)
|
|
|
|
return false;
|
|
|
|
assert(SP->getUnit());
|
|
|
|
auto EK = SP->getUnit()->getEmissionKind();
|
|
|
|
if (EK == DICompileUnit::NoDebug)
|
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2016-02-11 04:55:49 +08:00
|
|
|
void DebugHandlerBase::beginFunction(const MachineFunction *MF) {
|
2017-03-24 04:23:42 +08:00
|
|
|
PrevInstBB = nullptr;
|
2017-02-17 02:48:33 +08:00
|
|
|
|
2017-05-13 01:02:40 +08:00
|
|
|
if (!Asm || !hasDebugInfo(MMI, MF)) {
|
2017-02-17 02:48:33 +08:00
|
|
|
skippedNonDebugFunction();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-02-11 04:55:49 +08:00
|
|
|
// Grab the lexical scopes for the function, if we don't have any of those
|
|
|
|
// then we're not going to be able to do anything.
|
|
|
|
LScopes.initialize(*MF);
|
2017-02-17 02:48:33 +08:00
|
|
|
if (LScopes.empty()) {
|
|
|
|
beginFunctionImpl(MF);
|
2016-02-11 04:55:49 +08:00
|
|
|
return;
|
2017-02-17 02:48:33 +08:00
|
|
|
}
|
2016-02-11 04:55:49 +08:00
|
|
|
|
|
|
|
// Make sure that each lexical scope will have a begin/end label.
|
|
|
|
identifyScopeMarkers();
|
|
|
|
|
|
|
|
// Calculate history for local variables.
|
|
|
|
assert(DbgValues.empty() && "DbgValues map wasn't cleaned!");
|
2018-08-17 23:22:04 +08:00
|
|
|
assert(DbgLabels.empty() && "DbgLabels map wasn't cleaned!");
|
|
|
|
calculateDbgEntityHistory(MF, Asm->MF->getSubtarget().getRegisterInfo(),
|
|
|
|
DbgValues, DbgLabels);
|
2020-08-27 16:40:50 +08:00
|
|
|
InstOrdering.initialize(*MF);
|
2020-07-22 16:25:14 +08:00
|
|
|
if (TrimVarLocs)
|
2020-08-27 16:40:50 +08:00
|
|
|
DbgValues.trimLocationRanges(*MF, LScopes, InstOrdering);
|
2018-06-02 06:33:15 +08:00
|
|
|
LLVM_DEBUG(DbgValues.dump());
|
2016-02-11 04:55:49 +08:00
|
|
|
|
|
|
|
// Request labels for the full history.
|
|
|
|
for (const auto &I : DbgValues) {
|
2019-04-10 17:07:43 +08:00
|
|
|
const auto &Entries = I.second;
|
|
|
|
if (Entries.empty())
|
2016-02-11 04:55:49 +08:00
|
|
|
continue;
|
|
|
|
|
[DebugInfo] Stop changing labels for register-described parameter DBG_VALUEs
Summary:
This is a follow-up to D57510. This patch stops DebugHandlerBase from
changing the starting label for the first non-overlapping,
register-described parameter DBG_VALUEs to the beginning of the
function. That code did not consider what defined the registers, which
could result in the ranges for the debug values starting before their
defining instructions. We currently do not emit debug values for
constant values directly at the start of the function, so this code is
still useful for such values, but my intention is to remove the code
from DebugHandlerBase completely when we get there. One reason for
removing it is that the code violates the history map's ranges, which I
think can make it quite confusing when troubleshooting.
In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs
now are kept at the start of the entry block, even after emission of
prologue code. That was done to reduce the degradation of debug
completeness from this patch. PR40638 is another example, where the
lexical-scope trimming that LDV does, in combination with scheduling,
results in instructions after the prologue being left without locations.
There might be other cases where the DBG_VALUEs are pushed further down,
for which the DebugHandlerBase code may be helpful, but as it now quite
often result in incorrect locations, even after the prologue, it seems
better to remove that code, and try to work our way up with accurate
locations.
In the long run we should maybe not aim to provide accurate locations
inside the prologue. Some single location descriptions, at least those
referring to stack values, generate inaccurate values inside the
epilogue, so we maybe should not aim to achieve accuracy for location
lists. However, it seems that we now emit line number programs that can
result in GDB and LLDB stopping inside the prologue when doing line
number stepping into functions. See PR40188 for more information.
A summary of some of the changed test cases is available in PR40188#c2.
Reviewers: aprantl, dblaikie, rnk, jmorse
Reviewed By: aprantl
Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D57511
llvm-svn: 353928
2019-02-13 17:34:07 +08:00
|
|
|
auto IsDescribedByReg = [](const MachineInstr *MI) {
|
2021-03-10 22:35:55 +08:00
|
|
|
return any_of(MI->debug_operands(),
|
|
|
|
[](auto &MO) { return MO.isReg() && MO.getReg(); });
|
[DebugInfo] Stop changing labels for register-described parameter DBG_VALUEs
Summary:
This is a follow-up to D57510. This patch stops DebugHandlerBase from
changing the starting label for the first non-overlapping,
register-described parameter DBG_VALUEs to the beginning of the
function. That code did not consider what defined the registers, which
could result in the ranges for the debug values starting before their
defining instructions. We currently do not emit debug values for
constant values directly at the start of the function, so this code is
still useful for such values, but my intention is to remove the code
from DebugHandlerBase completely when we get there. One reason for
removing it is that the code violates the history map's ranges, which I
think can make it quite confusing when troubleshooting.
In D57510, PrologEpilogInserter was amended so that parameter DBG_VALUEs
now are kept at the start of the entry block, even after emission of
prologue code. That was done to reduce the degradation of debug
completeness from this patch. PR40638 is another example, where the
lexical-scope trimming that LDV does, in combination with scheduling,
results in instructions after the prologue being left without locations.
There might be other cases where the DBG_VALUEs are pushed further down,
for which the DebugHandlerBase code may be helpful, but as it now quite
often result in incorrect locations, even after the prologue, it seems
better to remove that code, and try to work our way up with accurate
locations.
In the long run we should maybe not aim to provide accurate locations
inside the prologue. Some single location descriptions, at least those
referring to stack values, generate inaccurate values inside the
epilogue, so we maybe should not aim to achieve accuracy for location
lists. However, it seems that we now emit line number programs that can
result in GDB and LLDB stopping inside the prologue when doing line
number stepping into functions. See PR40188 for more information.
A summary of some of the changed test cases is available in PR40188#c2.
Reviewers: aprantl, dblaikie, rnk, jmorse
Reviewed By: aprantl
Subscribers: jdoerfert, jholewinski, jvesely, javed.absar, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D57511
llvm-svn: 353928
2019-02-13 17:34:07 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// The first mention of a function argument gets the CurrentFnBegin label,
|
|
|
|
// so arguments are visible when breaking at function entry.
|
|
|
|
//
|
|
|
|
// We do not change the label for values that are described by registers,
|
|
|
|
// as that could place them above their defining instructions. We should
|
|
|
|
// ideally not change the labels for constant debug values either, since
|
|
|
|
// doing that violates the ranges that are calculated in the history map.
|
|
|
|
// However, we currently do not emit debug values for constant arguments
|
|
|
|
// directly at the start of the function, so this code is still useful.
|
2019-04-10 17:07:32 +08:00
|
|
|
const DILocalVariable *DIVar =
|
[DebugInfo] Improve handling of clobbered fragments
Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):
* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.
* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.
Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:
DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2
the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.
Changes to test cases:
* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.
* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.
Reviewers: aprantl, probinson, dblaikie, rnk, bjope
Reviewed By: aprantl
Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59941
llvm-svn: 358072
2019-04-10 19:28:20 +08:00
|
|
|
Entries.front().getInstr()->getDebugVariable();
|
2016-02-11 04:55:49 +08:00
|
|
|
if (DIVar->isParameter() &&
|
2021-06-02 03:38:32 +08:00
|
|
|
getDISubprogram(DIVar->getScope())->describes(&MF->getFunction())) {
|
[DebugInfo] Improve handling of clobbered fragments
Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):
* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.
* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.
Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:
DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2
the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.
Changes to test cases:
* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.
* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.
Reviewers: aprantl, probinson, dblaikie, rnk, bjope
Reviewed By: aprantl
Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59941
llvm-svn: 358072
2019-04-10 19:28:20 +08:00
|
|
|
if (!IsDescribedByReg(Entries.front().getInstr()))
|
|
|
|
LabelsBeforeInsn[Entries.front().getInstr()] = Asm->getFunctionBegin();
|
|
|
|
if (Entries.front().getInstr()->getDebugExpression()->isFragment()) {
|
2016-12-06 02:04:47 +08:00
|
|
|
// Mark all non-overlapping initial fragments.
|
2019-04-10 17:07:43 +08:00
|
|
|
for (auto I = Entries.begin(); I != Entries.end(); ++I) {
|
[DebugInfo] Improve handling of clobbered fragments
Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):
* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.
* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.
Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:
DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2
the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.
Changes to test cases:
* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.
* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.
Reviewers: aprantl, probinson, dblaikie, rnk, bjope
Reviewed By: aprantl
Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59941
llvm-svn: 358072
2019-04-10 19:28:20 +08:00
|
|
|
if (!I->isDbgValue())
|
|
|
|
continue;
|
|
|
|
const DIExpression *Fragment = I->getInstr()->getDebugExpression();
|
2019-04-10 17:07:43 +08:00
|
|
|
if (std::any_of(Entries.begin(), I,
|
|
|
|
[&](DbgValueHistoryMap::Entry Pred) {
|
[DebugInfo] Improve handling of clobbered fragments
Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):
* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.
* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.
Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:
DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2
the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.
Changes to test cases:
* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.
* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.
Reviewers: aprantl, probinson, dblaikie, rnk, bjope
Reviewed By: aprantl
Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59941
llvm-svn: 358072
2019-04-10 19:28:20 +08:00
|
|
|
return Pred.isDbgValue() &&
|
|
|
|
Fragment->fragmentsOverlap(
|
|
|
|
Pred.getInstr()->getDebugExpression());
|
2016-12-06 02:04:47 +08:00
|
|
|
}))
|
2016-02-11 04:55:49 +08:00
|
|
|
break;
|
Stop undef fragments from closing non-overlapping fragments
Summary:
When DwarfDebug::buildLocationList() encountered an undef debug value,
it would truncate all open values, regardless if they were overlapping or
not. This patch fixes so that it only does that for overlapping fragments.
This change unearthed a bug that I had introduced in D57511,
which I have fixed in this patch. The code in DebugHandlerBase that
changes labels for parameter debug values could break DwarfDebug's
assumption that the labels for the entries in the debug value history
are monotonically increasing. Before this patch, that bug could result
in location list entries whose ending address was lower than the
beginning address, and with the changes for undef debug values that this
patch introduces it could trigger an assertion, due to attempting to
emit location list entries with empty ranges. A reproducer for the bug
is added in param-reg-const-mix.mir.
Reviewers: aprantl, jmorse, probinson
Reviewed By: aprantl
Subscribers: javed.absar, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D62379
llvm-svn: 361820
2019-05-28 21:23:25 +08:00
|
|
|
// The code that generates location lists for DWARF assumes that the
|
|
|
|
// entries' start labels are monotonically increasing, and since we
|
|
|
|
// don't change the label for fragments that are described by
|
|
|
|
// registers, we must bail out when encountering such a fragment.
|
|
|
|
if (IsDescribedByReg(I->getInstr()))
|
|
|
|
break;
|
|
|
|
LabelsBeforeInsn[I->getInstr()] = Asm->getFunctionBegin();
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-10 17:07:43 +08:00
|
|
|
for (const auto &Entry : Entries) {
|
[DebugInfo] Improve handling of clobbered fragments
Summary:
Currently the DbgValueHistorymap only keeps track of clobbered registers
for the last debug value that it has encountered. This could lead to
preceding register-described debug values living on longer in the
location lists than they should. See PR40283 for an example. This
patch does not introduce tracking of multiple registers, but changes
the DbgValueHistoryMap structure to allow for that in a follow-up
patch. This patch is not NFC, as it at least fixes two bugs in
DwarfDebug (both are covered in the new clobbered-fragments.mir test):
* If a debug value was clobbered (its End pointer set), the value would
still be added to OpenRanges, meaning that the succeeding location list
entries could potentially contain stale values.
* If a debug value was clobbered, and there were non-overlapping
fragments that were still live after the clobbering, DwarfDebug would
not create a location list entry starting directly after the
clobbering instruction. This meant that the location list could have
a gap until the next debug value for the variable was encountered.
Before this patch, the history map was represented by <Begin, End>
pairs, where a new pair was created for each new debug value. When
dealing with partially overlapping register-described debug values, such
as in the following example:
DBG_VALUE $reg2, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 32, 32)
[...]
DBG_VALUE $reg3, $noreg, !1, !DIExpression(DW_OP_LLVM_fragment, 64, 32)
[...]
$reg2 = insn1
[...]
$reg3 = insn2
the history map would then contain the entries `[<DV1, insn1>, [<DV2, insn2>]`.
This would leave it up to the users of the map to be aware of
the relative order of the instructions, which e.g. could make
DwarfDebug::buildLocationList() needlessly complex. Instead, this patch
makes the history map structure monotonically increasing by dropping the
End pointer, and replacing that with explicit clobbering entries in the
vector. Each debug value has an "end index", which if set, points to the
entry in the vector that ends the debug value. The ending entry can
either be an overlapping debug value, or an instruction which clobbers
the register that the debug value is described by. The ending entry's
instruction can thus either be excluded or included in the debug value's
range. If the end index is not set, the debug value that the entry
introduces is valid until the end of the function.
Changes to test cases:
* DebugInfo/X86/pieces-3.ll: The range of the first DBG_VALUE, which
describes that the fragment (0, 64) is located in RDI, was
incorrectly ended by the clobbering of RAX, which the second
(non-overlapping) DBG_VALUE was described by. With this patch we
get a second entry that only describes RDI after that clobbering.
* DebugInfo/ARM/partial-subreg.ll: This test seems to indiciate a bug
in LiveDebugValues that is caused by it not being aware of fragments.
I have added some comments in the test case about that. Also, before
this patch DwarfDebug would incorrectly include a register-described
debug value from a preceding block in a location list entry.
Reviewers: aprantl, probinson, dblaikie, rnk, bjope
Reviewed By: aprantl
Subscribers: javed.absar, kristof.beyls, jdoerfert, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D59941
llvm-svn: 358072
2019-04-10 19:28:20 +08:00
|
|
|
if (Entry.isDbgValue())
|
|
|
|
requestLabelBeforeInsn(Entry.getInstr());
|
|
|
|
else
|
|
|
|
requestLabelAfterInsn(Entry.getInstr());
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-17 23:22:04 +08:00
|
|
|
// Ensure there is a symbol before DBG_LABEL.
|
|
|
|
for (const auto &I : DbgLabels) {
|
|
|
|
const MachineInstr *MI = I.second;
|
|
|
|
requestLabelBeforeInsn(MI);
|
|
|
|
}
|
|
|
|
|
2016-02-11 04:55:49 +08:00
|
|
|
PrevInstLoc = DebugLoc();
|
|
|
|
PrevLabel = Asm->getFunctionBegin();
|
2017-02-17 02:48:33 +08:00
|
|
|
beginFunctionImpl(MF);
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void DebugHandlerBase::beginInstruction(const MachineInstr *MI) {
|
2020-11-03 21:54:51 +08:00
|
|
|
if (!Asm || !MMI->hasDebugInfo())
|
2016-02-11 04:55:49 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
assert(CurMI == nullptr);
|
|
|
|
CurMI = MI;
|
|
|
|
|
|
|
|
// Insert labels where requested.
|
|
|
|
DenseMap<const MachineInstr *, MCSymbol *>::iterator I =
|
|
|
|
LabelsBeforeInsn.find(MI);
|
|
|
|
|
|
|
|
// No label needed.
|
|
|
|
if (I == LabelsBeforeInsn.end())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Label already assigned.
|
|
|
|
if (I->second)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!PrevLabel) {
|
|
|
|
PrevLabel = MMI->getContext().createTempSymbol();
|
2020-02-15 11:21:58 +08:00
|
|
|
Asm->OutStreamer->emitLabel(PrevLabel);
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
I->second = PrevLabel;
|
|
|
|
}
|
|
|
|
|
|
|
|
void DebugHandlerBase::endInstruction() {
|
2020-11-03 21:54:51 +08:00
|
|
|
if (!Asm || !MMI->hasDebugInfo())
|
2016-02-11 04:55:49 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
assert(CurMI != nullptr);
|
2017-05-23 04:47:09 +08:00
|
|
|
// Don't create a new label after DBG_VALUE and other instructions that don't
|
|
|
|
// generate code.
|
|
|
|
if (!CurMI->isMetaInstruction()) {
|
2016-02-11 04:55:49 +08:00
|
|
|
PrevLabel = nullptr;
|
2016-12-13 04:49:11 +08:00
|
|
|
PrevInstBB = CurMI->getParent();
|
|
|
|
}
|
2016-02-11 04:55:49 +08:00
|
|
|
|
|
|
|
DenseMap<const MachineInstr *, MCSymbol *>::iterator I =
|
|
|
|
LabelsAfterInsn.find(CurMI);
|
|
|
|
|
2021-06-02 03:38:32 +08:00
|
|
|
// No label needed or label already assigned.
|
|
|
|
if (I == LabelsAfterInsn.end() || I->second) {
|
|
|
|
CurMI = nullptr;
|
2021-05-27 23:40:51 +08:00
|
|
|
return;
|
2021-06-02 03:38:32 +08:00
|
|
|
}
|
2021-05-27 23:40:51 +08:00
|
|
|
|
2021-06-02 03:38:32 +08:00
|
|
|
// We need a label after this instruction. With basic block sections, just
|
|
|
|
// use the end symbol of the section if this is the last instruction of the
|
|
|
|
// section. This reduces the need for an additional label and also helps
|
|
|
|
// merging ranges.
|
|
|
|
if (CurMI->getParent()->isEndSection() && CurMI->getNextNode() == nullptr) {
|
|
|
|
PrevLabel = CurMI->getParent()->getEndSymbol();
|
|
|
|
} else if (!PrevLabel) {
|
2016-02-11 04:55:49 +08:00
|
|
|
PrevLabel = MMI->getContext().createTempSymbol();
|
2020-02-15 11:21:58 +08:00
|
|
|
Asm->OutStreamer->emitLabel(PrevLabel);
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
I->second = PrevLabel;
|
2021-06-02 03:38:32 +08:00
|
|
|
CurMI = nullptr;
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void DebugHandlerBase::endFunction(const MachineFunction *MF) {
|
2020-11-03 21:54:51 +08:00
|
|
|
if (Asm && hasDebugInfo(MMI, MF))
|
2017-02-17 02:48:33 +08:00
|
|
|
endFunctionImpl(MF);
|
2016-02-11 04:55:49 +08:00
|
|
|
DbgValues.clear();
|
2018-08-17 23:22:04 +08:00
|
|
|
DbgLabels.clear();
|
2016-02-11 04:55:49 +08:00
|
|
|
LabelsBeforeInsn.clear();
|
|
|
|
LabelsAfterInsn.clear();
|
2020-08-27 16:40:50 +08:00
|
|
|
InstOrdering.clear();
|
2016-02-11 04:55:49 +08:00
|
|
|
}
|
2020-07-02 14:47:30 +08:00
|
|
|
|
|
|
|
void DebugHandlerBase::beginBasicBlock(const MachineBasicBlock &MBB) {
|
|
|
|
if (!MBB.isBeginSection())
|
|
|
|
return;
|
|
|
|
|
|
|
|
PrevLabel = MBB.getSymbol();
|
|
|
|
}
|
|
|
|
|
|
|
|
void DebugHandlerBase::endBasicBlock(const MachineBasicBlock &MBB) {
|
|
|
|
if (!MBB.isEndSection())
|
|
|
|
return;
|
|
|
|
|
|
|
|
PrevLabel = nullptr;
|
|
|
|
}
|