2017-08-17 21:26:39 +00:00
|
|
|
//===- llvm/CodeGen/DwarfDebug.cpp - Dwarf Debug Framework ----------------===//
|
2009-05-15 09:23:25 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00: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
|
2009-05-15 09:23:25 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file contains support for writing dwarf debug info into asm files.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2010-03-09 00:39:24 +00:00
|
|
|
|
2009-05-15 09:23:25 +00:00
|
|
|
#include "DwarfDebug.h"
|
2014-10-04 15:49:50 +00:00
|
|
|
#include "ByteStreamer.h"
|
2013-08-08 23:45:55 +00:00
|
|
|
#include "DIEHash.h"
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
#include "DebugLocEntry.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "DebugLocStream.h"
|
2015-01-14 11:23:27 +00:00
|
|
|
#include "DwarfCompileUnit.h"
|
|
|
|
#include "DwarfExpression.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "DwarfFile.h"
|
2013-12-02 19:33:15 +00:00
|
|
|
#include "DwarfUnit.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/ADT/APInt.h"
|
|
|
|
#include "llvm/ADT/DenseMap.h"
|
|
|
|
#include "llvm/ADT/DenseSet.h"
|
|
|
|
#include "llvm/ADT/MapVector.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
|
|
|
#include "llvm/ADT/StringRef.h"
|
2019-07-31 16:51:28 +00:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/ADT/Triple.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2017-06-07 03:48:56 +00:00
|
|
|
#include "llvm/BinaryFormat/Dwarf.h"
|
2018-01-29 14:52:41 +00:00
|
|
|
#include "llvm/CodeGen/AccelTable.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/CodeGen/AsmPrinter.h"
|
2015-01-05 21:29:41 +00:00
|
|
|
#include "llvm/CodeGen/DIE.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/CodeGen/LexicalScopes.h"
|
|
|
|
#include "llvm/CodeGen/MachineBasicBlock.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/CodeGen/MachineFunction.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/CodeGen/MachineInstr.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/CodeGen/MachineModuleInfo.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/CodeGen/MachineOperand.h"
|
2018-10-05 20:37:17 +00:00
|
|
|
#include "llvm/CodeGen/TargetInstrInfo.h"
|
2019-07-31 16:51:28 +00:00
|
|
|
#include "llvm/CodeGen/TargetLowering.h"
|
2017-11-17 01:07:10 +00:00
|
|
|
#include "llvm/CodeGen/TargetRegisterInfo.h"
|
|
|
|
#include "llvm/CodeGen/TargetSubtargetInfo.h"
|
2019-03-19 13:16:28 +00:00
|
|
|
#include "llvm/DebugInfo/DWARF/DWARFExpression.h"
|
|
|
|
#include "llvm/DebugInfo/DWARF/DWARFDataExtractor.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Constants.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/IR/DebugInfoMetadata.h"
|
|
|
|
#include "llvm/IR/DebugLoc.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Module.h"
|
2010-03-09 01:58:53 +00:00
|
|
|
#include "llvm/MC/MCAsmInfo.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/MC/MCContext.h"
|
2015-08-07 15:14:08 +00:00
|
|
|
#include "llvm/MC/MCDwarf.h"
|
2009-07-31 18:48:30 +00:00
|
|
|
#include "llvm/MC/MCSection.h"
|
2009-08-19 05:49:37 +00:00
|
|
|
#include "llvm/MC/MCStreamer.h"
|
2010-03-09 01:58:53 +00:00
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/MC/MCTargetOptions.h"
|
|
|
|
#include "llvm/MC/MachineLocation.h"
|
|
|
|
#include "llvm/MC/SectionKind.h"
|
|
|
|
#include "llvm/Pass.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
2010-04-27 19:46:33 +00:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2009-10-13 06:47:08 +00:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2013-07-26 17:02:41 +00:00
|
|
|
#include "llvm/Support/MD5.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include "llvm/Support/MathExtras.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/Support/Timer.h"
|
2015-03-23 19:32:43 +00:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-03-23 23:58:19 +00:00
|
|
|
#include "llvm/Target/TargetLoweringObjectFile.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
|
|
|
#include "llvm/Target/TargetOptions.h"
|
2017-08-17 21:26:39 +00:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <iterator>
|
|
|
|
#include <string>
|
|
|
|
#include <utility>
|
|
|
|
#include <vector>
|
2016-02-02 18:20:45 +00:00
|
|
|
|
2009-05-15 09:23:25 +00:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 02:02:50 +00:00
|
|
|
#define DEBUG_TYPE "dwarfdebug"
|
|
|
|
|
2019-07-31 16:51:28 +00:00
|
|
|
STATISTIC(NumCSParams, "Number of dbg call site params created");
|
|
|
|
|
2013-07-23 22:16:41 +00:00
|
|
|
static cl::opt<bool>
|
|
|
|
DisableDebugInfoPrinting("disable-debug-info-print", cl::Hidden,
|
|
|
|
cl::desc("Disable debug info printing"));
|
2010-04-27 19:46:33 +00:00
|
|
|
|
2017-07-31 21:48:42 +00:00
|
|
|
static cl::opt<bool> UseDwarfRangesBaseAddressSpecifier(
|
|
|
|
"use-dwarf-ranges-base-address-specifier", cl::Hidden,
|
2017-08-01 14:50:50 +00:00
|
|
|
cl::desc("Use base address specifiers in debug_ranges"), cl::init(false));
|
2017-07-31 21:48:42 +00:00
|
|
|
|
2020-03-19 12:13:18 +01:00
|
|
|
static cl::opt<bool> EmitDwarfDebugEntryValues(
|
|
|
|
"emit-debug-entry-values", cl::Hidden,
|
|
|
|
cl::desc("Emit the debug entry values"), cl::init(false));
|
|
|
|
|
2014-02-14 01:26:55 +00:00
|
|
|
static cl::opt<bool> GenerateARangeSection("generate-arange-section",
|
|
|
|
cl::Hidden,
|
|
|
|
cl::desc("Generate dwarf aranges"),
|
|
|
|
cl::init(false));
|
|
|
|
|
[DebugInfo] Generate .debug_names section when it makes sense
Summary:
This patch makes us generate the debug_names section in response to some
user-facing commands (previously it was only generated if explicitly
selected via the -accel-tables option).
My goal was to make this work for DWARF>=5 (as it's an official part of
that standard), and also, as an extension, for DWARF<5 if one is
explicitly tuning for lldb as a debugger (because it brings a large
performance improvement there).
This is slightly complicated by the fact that the debug_names tables are
incompatible with the DWARF v4 type units (they assume that the type
units are in the debug_info section), and unfortunately, right now we
generate DWARF v4-style type units even for -gdwarf-5. For this reason,
I disable all accelerator tables if the user requested type unit
generation. I do this even for apple tables, as they have the same
problem (in fact generating type units for apple targets makes us crash
even before we get around to emitting the accelerator tables).
Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49420
llvm-svn: 337544
2018-07-20 12:59:05 +00:00
|
|
|
static cl::opt<bool>
|
|
|
|
GenerateDwarfTypeUnits("generate-type-units", cl::Hidden,
|
|
|
|
cl::desc("Generate DWARF4 type units."),
|
|
|
|
cl::init(false));
|
|
|
|
|
2017-05-12 01:13:45 +00:00
|
|
|
static cl::opt<bool> SplitDwarfCrossCuReferences(
|
|
|
|
"split-dwarf-cross-cu-references", cl::Hidden,
|
|
|
|
cl::desc("Enable cross-cu references in DWO files"), cl::init(false));
|
|
|
|
|
2014-01-27 23:50:03 +00:00
|
|
|
enum DefaultOnOff { Default, Enable, Disable };
|
2011-11-07 09:24:32 +00:00
|
|
|
|
2016-12-12 20:49:11 +00:00
|
|
|
static cl::opt<DefaultOnOff> UnknownLocations(
|
|
|
|
"use-unknown-locations", cl::Hidden,
|
|
|
|
cl::desc("Make an absence of debug location information explicit."),
|
|
|
|
cl::values(clEnumVal(Default, "At top of block or after label"),
|
|
|
|
clEnumVal(Enable, "In all cases"), clEnumVal(Disable, "Never")),
|
|
|
|
cl::init(Default));
|
|
|
|
|
2018-04-04 14:42:14 +00:00
|
|
|
static cl::opt<AccelTableKind> AccelTables(
|
|
|
|
"accel-tables", cl::Hidden, cl::desc("Output dwarf accelerator tables."),
|
|
|
|
cl::values(clEnumValN(AccelTableKind::Default, "Default",
|
|
|
|
"Default for platform"),
|
|
|
|
clEnumValN(AccelTableKind::None, "Disable", "Disabled."),
|
|
|
|
clEnumValN(AccelTableKind::Apple, "Apple", "Apple"),
|
|
|
|
clEnumValN(AccelTableKind::Dwarf, "Dwarf", "DWARF")),
|
|
|
|
cl::init(AccelTableKind::Default));
|
2012-08-23 22:36:40 +00:00
|
|
|
|
2018-02-20 15:28:08 +00:00
|
|
|
static cl::opt<DefaultOnOff>
|
|
|
|
DwarfInlinedStrings("dwarf-inlined-strings", cl::Hidden,
|
|
|
|
cl::desc("Use inlined strings rather than string section."),
|
|
|
|
cl::values(clEnumVal(Default, "Default for platform"),
|
|
|
|
clEnumVal(Enable, "Enabled"),
|
|
|
|
clEnumVal(Disable, "Disabled")),
|
|
|
|
cl::init(Default));
|
|
|
|
|
2018-03-20 20:21:38 +00:00
|
|
|
static cl::opt<bool>
|
|
|
|
NoDwarfRangesSection("no-dwarf-ranges-section", cl::Hidden,
|
|
|
|
cl::desc("Disable emission .debug_ranges section."),
|
|
|
|
cl::init(false));
|
|
|
|
|
2018-03-23 13:35:54 +00:00
|
|
|
static cl::opt<DefaultOnOff> DwarfSectionsAsReferences(
|
|
|
|
"dwarf-sections-as-references", cl::Hidden,
|
|
|
|
cl::desc("Use sections+offset as references rather than labels."),
|
|
|
|
cl::values(clEnumVal(Default, "Default for platform"),
|
|
|
|
clEnumVal(Enable, "Enabled"), clEnumVal(Disable, "Disabled")),
|
|
|
|
cl::init(Default));
|
|
|
|
|
2016-04-18 22:41:41 +00:00
|
|
|
enum LinkageNameOption {
|
|
|
|
DefaultLinkageNames,
|
|
|
|
AllLinkageNames,
|
|
|
|
AbstractLinkageNames
|
|
|
|
};
|
2017-08-17 21:26:39 +00:00
|
|
|
|
2016-04-18 22:41:41 +00:00
|
|
|
static cl::opt<LinkageNameOption>
|
|
|
|
DwarfLinkageNames("dwarf-linkage-names", cl::Hidden,
|
|
|
|
cl::desc("Which DWARF linkage-name attributes to emit."),
|
|
|
|
cl::values(clEnumValN(DefaultLinkageNames, "Default",
|
|
|
|
"Default for platform"),
|
|
|
|
clEnumValN(AllLinkageNames, "All", "All"),
|
|
|
|
clEnumValN(AbstractLinkageNames, "Abstract",
|
2016-10-08 19:41:06 +00:00
|
|
|
"Abstract subprograms")),
|
2016-04-18 22:41:41 +00:00
|
|
|
cl::init(DefaultLinkageNames));
|
2015-08-11 21:36:45 +00:00
|
|
|
|
2016-11-18 19:43:18 +00:00
|
|
|
static const char *const DWARFGroupName = "dwarf";
|
|
|
|
static const char *const DWARFGroupDescription = "DWARF Emission";
|
|
|
|
static const char *const DbgTimerName = "writer";
|
|
|
|
static const char *const DbgTimerDescription = "DWARF Debug Writer";
|
2019-03-19 13:16:28 +00:00
|
|
|
static constexpr unsigned ULEB128PadSize = 4;
|
2010-04-07 09:28:04 +00:00
|
|
|
|
2017-03-16 17:42:45 +00:00
|
|
|
void DebugLocDwarfExpression::emitOp(uint8_t Op, const char *Comment) {
|
[DebugInfo] Add interface for pre-calculating the size of emitted DWARF
Summary:
DWARF's DW_OP_entry_value operation has two operands; the first is a
ULEB128 operand that specifies the size of the second operand, which is
a DWARF block. This means that we need to be able to pre-calculate and
emit the size of DWARF expressions before emitting them. There is
currently no interface for doing this in DwarfExpression, so this patch
introduces that.
When implementing this I initially thought about running through
DwarfExpression's emission two times; first with a temporary buffer to
emit the expression, in order to being able to calculate the size of
that emitted data. However, DwarfExpression is a quite complex state
machine, so I decided against that, as it seemed like the two runs could
get out of sync, resulting in incorrect size operands. Therefore I have
implemented this in a way that we only have to run DwarfExpression once.
The idea is to emit DWARF to a temporary buffer, for which it is
possible to query the size. The data in the temporary buffer can then be
emitted to DwarfExpression's main output.
In the case of DIEDwarfExpression, a temporary DIE is used. The values
are all allocated using the same BumpPtrAllocator as for all other DIEs,
and the values are then transferred to the real value list. In the case
of DebugLocDwarfExpression, the temporary buffer is implemented using a
BufferByteStreamer which emits to a buffer in the DwarfExpression
object.
Reviewers: aprantl, vsk, NikolaPrica, djtodoro
Reviewed By: aprantl
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67768
llvm-svn: 374879
2019-10-15 11:14:35 +00:00
|
|
|
getActiveStreamer().EmitInt8(
|
2015-03-02 22:02:33 +00:00
|
|
|
Op, Comment ? Twine(Comment) + " " + dwarf::OperationEncodingString(Op)
|
|
|
|
: dwarf::OperationEncodingString(Op));
|
|
|
|
}
|
|
|
|
|
2017-03-16 17:42:45 +00:00
|
|
|
void DebugLocDwarfExpression::emitSigned(int64_t Value) {
|
2020-02-13 13:26:21 -08:00
|
|
|
getActiveStreamer().emitSLEB128(Value, Twine(Value));
|
2015-03-02 22:02:33 +00:00
|
|
|
}
|
|
|
|
|
2017-03-16 17:42:45 +00:00
|
|
|
void DebugLocDwarfExpression::emitUnsigned(uint64_t Value) {
|
2020-02-13 13:26:21 -08:00
|
|
|
getActiveStreamer().emitULEB128(Value, Twine(Value));
|
2015-03-02 22:02:33 +00:00
|
|
|
}
|
|
|
|
|
2019-04-30 07:58:57 +00:00
|
|
|
void DebugLocDwarfExpression::emitData1(uint8_t Value) {
|
[DebugInfo] Add interface for pre-calculating the size of emitted DWARF
Summary:
DWARF's DW_OP_entry_value operation has two operands; the first is a
ULEB128 operand that specifies the size of the second operand, which is
a DWARF block. This means that we need to be able to pre-calculate and
emit the size of DWARF expressions before emitting them. There is
currently no interface for doing this in DwarfExpression, so this patch
introduces that.
When implementing this I initially thought about running through
DwarfExpression's emission two times; first with a temporary buffer to
emit the expression, in order to being able to calculate the size of
that emitted data. However, DwarfExpression is a quite complex state
machine, so I decided against that, as it seemed like the two runs could
get out of sync, resulting in incorrect size operands. Therefore I have
implemented this in a way that we only have to run DwarfExpression once.
The idea is to emit DWARF to a temporary buffer, for which it is
possible to query the size. The data in the temporary buffer can then be
emitted to DwarfExpression's main output.
In the case of DIEDwarfExpression, a temporary DIE is used. The values
are all allocated using the same BumpPtrAllocator as for all other DIEs,
and the values are then transferred to the real value list. In the case
of DebugLocDwarfExpression, the temporary buffer is implemented using a
BufferByteStreamer which emits to a buffer in the DwarfExpression
object.
Reviewers: aprantl, vsk, NikolaPrica, djtodoro
Reviewed By: aprantl
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67768
llvm-svn: 374879
2019-10-15 11:14:35 +00:00
|
|
|
getActiveStreamer().EmitInt8(Value, Twine(Value));
|
2019-04-30 07:58:57 +00:00
|
|
|
}
|
|
|
|
|
2019-03-19 13:16:28 +00:00
|
|
|
void DebugLocDwarfExpression::emitBaseTypeRef(uint64_t Idx) {
|
|
|
|
assert(Idx < (1ULL << (ULEB128PadSize * 7)) && "Idx wont fit");
|
2020-02-13 13:26:21 -08:00
|
|
|
getActiveStreamer().emitULEB128(Idx, Twine(Idx), ULEB128PadSize);
|
2019-03-19 13:16:28 +00:00
|
|
|
}
|
|
|
|
|
2016-05-20 19:35:17 +00:00
|
|
|
bool DebugLocDwarfExpression::isFrameRegister(const TargetRegisterInfo &TRI,
|
|
|
|
unsigned MachineReg) {
|
2015-03-02 22:02:33 +00:00
|
|
|
// This information is not available while emitting .debug_loc entries.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
[DebugInfo] Add interface for pre-calculating the size of emitted DWARF
Summary:
DWARF's DW_OP_entry_value operation has two operands; the first is a
ULEB128 operand that specifies the size of the second operand, which is
a DWARF block. This means that we need to be able to pre-calculate and
emit the size of DWARF expressions before emitting them. There is
currently no interface for doing this in DwarfExpression, so this patch
introduces that.
When implementing this I initially thought about running through
DwarfExpression's emission two times; first with a temporary buffer to
emit the expression, in order to being able to calculate the size of
that emitted data. However, DwarfExpression is a quite complex state
machine, so I decided against that, as it seemed like the two runs could
get out of sync, resulting in incorrect size operands. Therefore I have
implemented this in a way that we only have to run DwarfExpression once.
The idea is to emit DWARF to a temporary buffer, for which it is
possible to query the size. The data in the temporary buffer can then be
emitted to DwarfExpression's main output.
In the case of DIEDwarfExpression, a temporary DIE is used. The values
are all allocated using the same BumpPtrAllocator as for all other DIEs,
and the values are then transferred to the real value list. In the case
of DebugLocDwarfExpression, the temporary buffer is implemented using a
BufferByteStreamer which emits to a buffer in the DwarfExpression
object.
Reviewers: aprantl, vsk, NikolaPrica, djtodoro
Reviewed By: aprantl
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67768
llvm-svn: 374879
2019-10-15 11:14:35 +00:00
|
|
|
void DebugLocDwarfExpression::enableTemporaryBuffer() {
|
|
|
|
assert(!IsBuffering && "Already buffering?");
|
|
|
|
if (!TmpBuf)
|
|
|
|
TmpBuf = std::make_unique<TempBuffer>(OutBS.GenerateComments);
|
|
|
|
IsBuffering = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void DebugLocDwarfExpression::disableTemporaryBuffer() { IsBuffering = false; }
|
|
|
|
|
|
|
|
unsigned DebugLocDwarfExpression::getTemporaryBufferSize() {
|
|
|
|
return TmpBuf ? TmpBuf->Bytes.size() : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void DebugLocDwarfExpression::commitTemporaryBuffer() {
|
|
|
|
if (!TmpBuf)
|
|
|
|
return;
|
|
|
|
for (auto Byte : enumerate(TmpBuf->Bytes)) {
|
|
|
|
const char *Comment = (Byte.index() < TmpBuf->Comments.size())
|
|
|
|
? TmpBuf->Comments[Byte.index()].c_str()
|
|
|
|
: "";
|
|
|
|
OutBS.EmitInt8(Byte.value(), Comment);
|
|
|
|
}
|
|
|
|
TmpBuf->Bytes.clear();
|
|
|
|
TmpBuf->Comments.clear();
|
|
|
|
}
|
|
|
|
|
2015-04-29 16:38:44 +00:00
|
|
|
const DIType *DbgVariable::getType() const {
|
2019-09-18 22:38:56 +00:00
|
|
|
return getVariable()->getType();
|
2011-04-12 22:53:02 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
/// Get .debug_loc entry for the instruction range starting at MI.
|
2019-06-13 10:23:26 +00:00
|
|
|
static DbgValueLoc getDebugLocValue(const MachineInstr *MI) {
|
2019-06-10 08:41:06 +00:00
|
|
|
const DIExpression *Expr = MI->getDebugExpression();
|
|
|
|
assert(MI->getNumOperands() == 4);
|
|
|
|
if (MI->getOperand(0).isReg()) {
|
|
|
|
auto RegOp = MI->getOperand(0);
|
|
|
|
auto Op1 = MI->getOperand(1);
|
|
|
|
// If the second operand is an immediate, this is a
|
|
|
|
// register-indirect address.
|
|
|
|
assert((!Op1.isImm() || (Op1.getImm() == 0)) && "unexpected offset");
|
|
|
|
MachineLocation MLoc(RegOp.getReg(), Op1.isImm());
|
2019-06-13 10:23:26 +00:00
|
|
|
return DbgValueLoc(Expr, MLoc);
|
2019-06-10 08:41:06 +00:00
|
|
|
}
|
2019-12-20 14:31:56 -08:00
|
|
|
if (MI->getOperand(0).isTargetIndex()) {
|
|
|
|
auto Op = MI->getOperand(0);
|
|
|
|
return DbgValueLoc(Expr,
|
|
|
|
TargetIndexLocation(Op.getIndex(), Op.getOffset()));
|
|
|
|
}
|
2019-06-10 08:41:06 +00:00
|
|
|
if (MI->getOperand(0).isImm())
|
2019-06-13 10:23:26 +00:00
|
|
|
return DbgValueLoc(Expr, MI->getOperand(0).getImm());
|
2019-06-10 08:41:06 +00:00
|
|
|
if (MI->getOperand(0).isFPImm())
|
2019-06-13 10:23:26 +00:00
|
|
|
return DbgValueLoc(Expr, MI->getOperand(0).getFPImm());
|
2019-06-10 08:41:06 +00:00
|
|
|
if (MI->getOperand(0).isCImm())
|
2019-06-13 10:23:26 +00:00
|
|
|
return DbgValueLoc(Expr, MI->getOperand(0).getCImm());
|
2019-06-10 08:41:06 +00:00
|
|
|
|
|
|
|
llvm_unreachable("Unexpected 4-operand DBG_VALUE instruction!");
|
|
|
|
}
|
|
|
|
|
|
|
|
void DbgVariable::initializeDbgValue(const MachineInstr *DbgValue) {
|
|
|
|
assert(FrameIndexExprs.empty() && "Already initialized?");
|
|
|
|
assert(!ValueLoc.get() && "Already initialized?");
|
|
|
|
|
|
|
|
assert(getVariable() == DbgValue->getDebugVariable() && "Wrong variable");
|
|
|
|
assert(getInlinedAt() == DbgValue->getDebugLoc()->getInlinedAt() &&
|
|
|
|
"Wrong inlined-at");
|
|
|
|
|
2019-08-15 15:54:37 +00:00
|
|
|
ValueLoc = std::make_unique<DbgValueLoc>(getDebugLocValue(DbgValue));
|
2019-06-10 08:41:06 +00:00
|
|
|
if (auto *E = DbgValue->getDebugExpression())
|
|
|
|
if (E->getNumElements())
|
|
|
|
FrameIndexExprs.push_back({0, E});
|
|
|
|
}
|
|
|
|
|
2017-02-17 19:42:32 +00:00
|
|
|
ArrayRef<DbgVariable::FrameIndexExpr> DbgVariable::getFrameIndexExprs() const {
|
2017-03-22 16:50:16 +00:00
|
|
|
if (FrameIndexExprs.size() == 1)
|
|
|
|
return FrameIndexExprs;
|
|
|
|
|
2017-08-17 21:26:39 +00:00
|
|
|
assert(llvm::all_of(FrameIndexExprs,
|
|
|
|
[](const FrameIndexExpr &A) {
|
|
|
|
return A.Expr->isFragment();
|
|
|
|
}) &&
|
2017-03-22 16:50:16 +00:00
|
|
|
"multiple FI expressions without DW_OP_LLVM_fragment");
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 02:13:45 +00:00
|
|
|
llvm::sort(FrameIndexExprs,
|
2018-04-06 18:08:42 +00:00
|
|
|
[](const FrameIndexExpr &A, const FrameIndexExpr &B) -> bool {
|
|
|
|
return A.Expr->getFragmentInfo()->OffsetInBits <
|
|
|
|
B.Expr->getFragmentInfo()->OffsetInBits;
|
|
|
|
});
|
2017-10-10 07:46:17 +00:00
|
|
|
|
2017-02-17 19:42:32 +00:00
|
|
|
return FrameIndexExprs;
|
|
|
|
}
|
|
|
|
|
2017-10-10 07:46:17 +00:00
|
|
|
void DbgVariable::addMMIEntry(const DbgVariable &V) {
|
2019-06-10 08:41:06 +00:00
|
|
|
assert(DebugLocListIndex == ~0U && !ValueLoc.get() && "not an MMI entry");
|
|
|
|
assert(V.DebugLocListIndex == ~0U && !V.ValueLoc.get() && "not an MMI entry");
|
2018-08-17 15:22:04 +00:00
|
|
|
assert(V.getVariable() == getVariable() && "conflicting variable");
|
|
|
|
assert(V.getInlinedAt() == getInlinedAt() && "conflicting inlined-at location");
|
2017-10-10 07:46:17 +00:00
|
|
|
|
|
|
|
assert(!FrameIndexExprs.empty() && "Expected an MMI entry");
|
|
|
|
assert(!V.FrameIndexExprs.empty() && "Expected an MMI entry");
|
|
|
|
|
2017-10-12 13:25:05 +00:00
|
|
|
// FIXME: This logic should not be necessary anymore, as we now have proper
|
|
|
|
// deduplication. However, without it, we currently run into the assertion
|
|
|
|
// below, which means that we are likely dealing with broken input, i.e. two
|
|
|
|
// non-fragment entries for the same variable at different frame indices.
|
|
|
|
if (FrameIndexExprs.size()) {
|
|
|
|
auto *Expr = FrameIndexExprs.back().Expr;
|
|
|
|
if (!Expr || !Expr->isFragment())
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-10-10 07:46:17 +00:00
|
|
|
for (const auto &FIE : V.FrameIndexExprs)
|
|
|
|
// Ignore duplicate entries.
|
|
|
|
if (llvm::none_of(FrameIndexExprs, [&](const FrameIndexExpr &Other) {
|
|
|
|
return FIE.FI == Other.FI && FIE.Expr == Other.Expr;
|
|
|
|
}))
|
|
|
|
FrameIndexExprs.push_back(FIE);
|
|
|
|
|
|
|
|
assert((FrameIndexExprs.size() == 1 ||
|
|
|
|
llvm::all_of(FrameIndexExprs,
|
|
|
|
[](FrameIndexExpr &FIE) {
|
|
|
|
return FIE.Expr && FIE.Expr->isFragment();
|
|
|
|
})) &&
|
|
|
|
"conflicting locations for variable");
|
|
|
|
}
|
|
|
|
|
[DebugInfo] Generate .debug_names section when it makes sense
Summary:
This patch makes us generate the debug_names section in response to some
user-facing commands (previously it was only generated if explicitly
selected via the -accel-tables option).
My goal was to make this work for DWARF>=5 (as it's an official part of
that standard), and also, as an extension, for DWARF<5 if one is
explicitly tuning for lldb as a debugger (because it brings a large
performance improvement there).
This is slightly complicated by the fact that the debug_names tables are
incompatible with the DWARF v4 type units (they assume that the type
units are in the debug_info section), and unfortunately, right now we
generate DWARF v4-style type units even for -gdwarf-5. For this reason,
I disable all accelerator tables if the user requested type unit
generation. I do this even for apple tables, as they have the same
problem (in fact generating type units for apple targets makes us crash
even before we get around to emitting the accelerator tables).
Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49420
llvm-svn: 337544
2018-07-20 12:59:05 +00:00
|
|
|
static AccelTableKind computeAccelTableKind(unsigned DwarfVersion,
|
|
|
|
bool GenerateTypeUnits,
|
|
|
|
DebuggerKind Tuning,
|
|
|
|
const Triple &TT) {
|
|
|
|
// Honor an explicit request.
|
|
|
|
if (AccelTables != AccelTableKind::Default)
|
|
|
|
return AccelTables;
|
|
|
|
|
|
|
|
// Accelerator tables with type units are currently not supported.
|
|
|
|
if (GenerateTypeUnits)
|
|
|
|
return AccelTableKind::None;
|
|
|
|
|
|
|
|
// Accelerator tables get emitted if targetting DWARF v5 or LLDB. DWARF v5
|
|
|
|
// always implies debug_names. For lower standard versions we use apple
|
|
|
|
// accelerator tables on apple platforms and debug_names elsewhere.
|
|
|
|
if (DwarfVersion >= 5)
|
|
|
|
return AccelTableKind::Dwarf;
|
|
|
|
if (Tuning == DebuggerKind::LLDB)
|
|
|
|
return TT.isOSBinFormatMachO() ? AccelTableKind::Apple
|
|
|
|
: AccelTableKind::Dwarf;
|
|
|
|
return AccelTableKind::None;
|
|
|
|
}
|
|
|
|
|
2010-04-05 05:11:15 +00:00
|
|
|
DwarfDebug::DwarfDebug(AsmPrinter *A, Module *M)
|
2016-02-10 20:55:49 +00:00
|
|
|
: DebugHandlerBase(A), DebugLocs(A->OutStreamer->isVerboseAsm()),
|
|
|
|
InfoHolder(A, "info_string", DIEValueAllocator),
|
2015-03-04 02:30:17 +00:00
|
|
|
SkeletonHolder(A, "skel_string", DIEValueAllocator),
|
[CodeGen] Refactor AppleAccelTable
Summary:
This commit separates the abstract accelerator table data structure
from the code for writing out an on-disk representation of a specific
accelerator table format. The idea is that former (now called
AccelTable<T>) can be reused for the DWARF v5 accelerator tables
as-is, without any further customizations.
Some bits of the emission code (now living in the EmissionContext class)
can be reused for DWARF v5 as well, but the subtle differences in the
layout of various subtables mean the sharing is not always possible.
(Also, the individual emit*** functions are fairly simple so there's a
tradeoff between making a bigger general-purpose function, and two
smaller targeted functions.)
Another advantage of this setup is that more of the serialization logic
can be hidden in the .cpp file -- I have moved declarations of the
header and all the emission functions there.
Reviewers: JDevlieghere, aprantl, probinson, dblaikie
Subscribers: echristo, clayborg, vleschuk, llvm-commits
Differential Revision: https://reviews.llvm.org/D43285
llvm-svn: 325516
2018-02-19 16:12:20 +00:00
|
|
|
IsDarwin(A->TM.getTargetTriple().isOSDarwin()) {
|
2016-10-01 01:50:29 +00:00
|
|
|
const Triple &TT = Asm->TM.getTargetTriple();
|
2015-07-15 22:04:54 +00:00
|
|
|
|
2019-01-25 16:29:35 +00:00
|
|
|
// Make sure we know our "debugger tuning". The target option takes
|
2015-07-15 22:04:54 +00:00
|
|
|
// precedence; fall back to triple-based defaults.
|
2015-12-16 19:58:30 +00:00
|
|
|
if (Asm->TM.Options.DebuggerTuning != DebuggerKind::Default)
|
|
|
|
DebuggerTuning = Asm->TM.Options.DebuggerTuning;
|
Turn off lldb debug tuning by default for FreeBSD
Summary:
In rL242338, debugger tuning was introduced, and the tuning for FreeBSD
was set to lldb by default. However, for the foreseeable future we
still need to default to gdb tuning, since lldb is not ready for all of
FreeBSD's architectures, and some system tools (like objcopy, etc) have
not yet been adapted to cope with the lldb tuned format, which has
.apple sections.
Therefore, let FreeBSD use gdb by default for now.
Reviewers: emaste, probinson
Subscribers: llvm-commits, emaste
Differential Revision: http://reviews.llvm.org/D15966
llvm-svn: 257103
2016-01-07 22:09:12 +00:00
|
|
|
else if (IsDarwin)
|
2015-07-15 22:04:54 +00:00
|
|
|
DebuggerTuning = DebuggerKind::LLDB;
|
|
|
|
else if (TT.isPS4CPU())
|
|
|
|
DebuggerTuning = DebuggerKind::SCE;
|
|
|
|
else
|
|
|
|
DebuggerTuning = DebuggerKind::GDB;
|
2012-04-02 17:58:52 +00:00
|
|
|
|
2018-05-18 03:13:08 +00:00
|
|
|
if (DwarfInlinedStrings == Default)
|
|
|
|
UseInlineStrings = TT.isNVPTX();
|
|
|
|
else
|
|
|
|
UseInlineStrings = DwarfInlinedStrings == Enable;
|
|
|
|
|
2018-06-29 14:23:28 +00:00
|
|
|
UseLocSection = !TT.isNVPTX();
|
|
|
|
|
2016-05-24 21:19:28 +00:00
|
|
|
HasAppleExtensionAttributes = tuneForLLDB();
|
|
|
|
|
2017-04-21 23:35:26 +00:00
|
|
|
// Handle split DWARF.
|
|
|
|
HasSplitDwarf = !Asm->TM.Options.MCOptions.SplitDwarfFile.empty();
|
2013-08-19 21:41:38 +00:00
|
|
|
|
2016-04-18 22:41:41 +00:00
|
|
|
// SCE defaults to linkage names only for abstract subprograms.
|
|
|
|
if (DwarfLinkageNames == DefaultLinkageNames)
|
|
|
|
UseAllLinkageNames = !tuneForSCE();
|
2015-08-11 21:36:45 +00:00
|
|
|
else
|
2016-04-18 22:41:41 +00:00
|
|
|
UseAllLinkageNames = DwarfLinkageNames == AllLinkageNames;
|
2015-08-11 21:36:45 +00:00
|
|
|
|
2014-06-19 06:22:08 +00:00
|
|
|
unsigned DwarfVersionNumber = Asm->TM.Options.MCOptions.DwarfVersion;
|
2016-11-23 23:30:37 +00:00
|
|
|
unsigned DwarfVersion = DwarfVersionNumber ? DwarfVersionNumber
|
2014-04-28 20:42:22 +00:00
|
|
|
: MMI->getModule()->getDwarfVersion();
|
2018-05-18 03:13:08 +00:00
|
|
|
// Use dwarf 4 by default if nothing is requested. For NVPTX, use dwarf 2.
|
|
|
|
DwarfVersion =
|
|
|
|
TT.isNVPTX() ? 2 : (DwarfVersion ? DwarfVersion : dwarf::DWARF_VERSION);
|
2013-07-02 23:40:10 +00:00
|
|
|
|
2018-05-18 03:13:08 +00:00
|
|
|
UseRangesSection = !NoDwarfRangesSection && !TT.isNVPTX();
|
2018-03-20 16:04:40 +00:00
|
|
|
|
2018-05-18 03:13:08 +00:00
|
|
|
// Use sections as references. Force for NVPTX.
|
|
|
|
if (DwarfSectionsAsReferences == Default)
|
|
|
|
UseSectionsAsReferences = TT.isNVPTX();
|
|
|
|
else
|
|
|
|
UseSectionsAsReferences = DwarfSectionsAsReferences == Enable;
|
2018-03-23 13:35:54 +00:00
|
|
|
|
2018-08-01 12:53:06 +00:00
|
|
|
// Don't generate type units for unsupported object file formats.
|
|
|
|
GenerateTypeUnits =
|
|
|
|
A->TM.getTargetTriple().isOSBinFormatELF() && GenerateDwarfTypeUnits;
|
[DebugInfo] Generate .debug_names section when it makes sense
Summary:
This patch makes us generate the debug_names section in response to some
user-facing commands (previously it was only generated if explicitly
selected via the -accel-tables option).
My goal was to make this work for DWARF>=5 (as it's an official part of
that standard), and also, as an extension, for DWARF<5 if one is
explicitly tuning for lldb as a debugger (because it brings a large
performance improvement there).
This is slightly complicated by the fact that the debug_names tables are
incompatible with the DWARF v4 type units (they assume that the type
units are in the debug_info section), and unfortunately, right now we
generate DWARF v4-style type units even for -gdwarf-5. For this reason,
I disable all accelerator tables if the user requested type unit
generation. I do this even for apple tables, as they have the same
problem (in fact generating type units for apple targets makes us crash
even before we get around to emitting the accelerator tables).
Reviewers: JDevlieghere, aprantl, dblaikie, echristo, probinson
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49420
llvm-svn: 337544
2018-07-20 12:59:05 +00:00
|
|
|
|
|
|
|
TheAccelTableKind = computeAccelTableKind(
|
|
|
|
DwarfVersion, GenerateTypeUnits, DebuggerTuning, A->TM.getTargetTriple());
|
|
|
|
|
2015-07-15 22:04:54 +00:00
|
|
|
// Work around a GDB bug. GDB doesn't support the standard opcode;
|
|
|
|
// SCE doesn't support GNU's; LLDB prefers the standard opcode, which
|
|
|
|
// is defined as of DWARF 3.
|
|
|
|
// See GDB bug 11616 - DW_OP_form_tls_address is unimplemented
|
|
|
|
// https://sourceware.org/bugzilla/show_bug.cgi?id=11616
|
|
|
|
UseGNUTLSOpcode = tuneForGDB() || DwarfVersion < 3;
|
2015-03-04 20:55:11 +00:00
|
|
|
|
2016-05-17 21:07:16 +00:00
|
|
|
// GDB does not fully support the DWARF 4 representation for bitfields.
|
|
|
|
UseDWARF2Bitfields = (DwarfVersion < 4) || tuneForGDB();
|
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
// The DWARF v5 string offsets table has - possibly shared - contributions
|
|
|
|
// from each compile and type unit each preceded by a header. The string
|
|
|
|
// offsets table used by the pre-DWARF v5 split-DWARF implementation uses
|
|
|
|
// a monolithic string offsets table without any header.
|
|
|
|
UseSegmentedStringOffsetsTable = DwarfVersion >= 5;
|
|
|
|
|
2020-03-19 12:13:18 +01:00
|
|
|
// Emit call-site-param debug info for GDB and LLDB, if the target supports
|
|
|
|
// the debug entry values feature. It can also be enabled explicitly.
|
|
|
|
EmitDebugEntryValues = (Asm->TM.Options.ShouldEmitDebugEntryValues() &&
|
|
|
|
(tuneForGDB() || tuneForLLDB())) ||
|
|
|
|
EmitDwarfDebugEntryValues;
|
|
|
|
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->getContext().setDwarfVersion(DwarfVersion);
|
2009-05-15 09:23:25 +00:00
|
|
|
}
|
|
|
|
|
2014-04-30 20:34:31 +00:00
|
|
|
// Define out of line so we don't have to include DwarfUnit.h in DwarfDebug.h.
|
2017-08-17 21:26:39 +00:00
|
|
|
DwarfDebug::~DwarfDebug() = default;
|
2014-04-30 20:34:31 +00:00
|
|
|
|
2011-11-10 19:25:34 +00:00
|
|
|
static bool isObjCClass(StringRef Name) {
|
|
|
|
return Name.startswith("+") || Name.startswith("-");
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool hasObjCCategory(StringRef Name) {
|
2013-11-19 09:04:36 +00:00
|
|
|
if (!isObjCClass(Name))
|
|
|
|
return false;
|
2011-11-10 19:25:34 +00:00
|
|
|
|
2013-08-24 12:15:54 +00:00
|
|
|
return Name.find(") ") != StringRef::npos;
|
2011-11-10 19:25:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static void getObjCClassCategory(StringRef In, StringRef &Class,
|
|
|
|
StringRef &Category) {
|
|
|
|
if (!hasObjCCategory(In)) {
|
|
|
|
Class = In.slice(In.find('[') + 1, In.find(' '));
|
|
|
|
Category = "";
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Class = In.slice(In.find('[') + 1, In.find('('));
|
|
|
|
Category = In.slice(In.find('[') + 1, In.find(' '));
|
|
|
|
}
|
|
|
|
|
|
|
|
static StringRef getObjCMethodName(StringRef In) {
|
|
|
|
return In.slice(In.find(' ') + 1, In.find(']'));
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add the various names to the Dwarf accelerator table names.
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addSubprogramNames(const DICompileUnit &CU,
|
|
|
|
const DISubprogram *SP, DIE &Die) {
|
|
|
|
if (getAccelTableKind() != AccelTableKind::Apple &&
|
|
|
|
CU.getNameTableKind() == DICompileUnit::DebugNameTableKind::None)
|
|
|
|
return;
|
|
|
|
|
2015-04-14 03:40:37 +00:00
|
|
|
if (!SP->isDefinition())
|
2013-11-19 09:04:36 +00:00
|
|
|
return;
|
[CodeGen/AccelTable]: Don't emit accelerator entries for functions with no names
Summary:
We were emitting accelerator entries for functions with no name, which
is contrary to the DWARF v5 spec: "All other (i.e., *not*
DW_TAG_namespace) debugging information entries without a DW_AT_name
attribute are excluded." Besides that, a name table entry with an empty
string as a key is fairly useless.
We can sometimes end up with functions which have a DW_AT_linkage_name but no
DW_AT_name. One such example is the global-constructor-initialization functions,
which C++ compilers synthesize for each compilation unit with global
constructors.
A very strict reading of the DWARF v5 spec would suggest that we should not even
emit the accelerator entry for the linkage name in this case, but I don't think
we should go that far.
I found this when running the dwarf verifier over llvm codebase compiled
with DWARF v5 accelerator tables.
Reviewers: JDevlieghere, aprantl, dblaikie
Subscribers: vleschuk, clayborg, echristo, probinson, llvm-commits
Differential Revision: https://reviews.llvm.org/D45367
llvm-svn: 329552
2018-04-09 08:41:57 +00:00
|
|
|
|
|
|
|
if (SP->getName() != "")
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelName(CU, SP->getName(), Die);
|
2011-11-10 19:25:34 +00:00
|
|
|
|
2018-05-14 14:13:20 +00:00
|
|
|
// If the linkage name is different than the name, go ahead and output that as
|
|
|
|
// well into the name table. Only do that if we are going to actually emit
|
|
|
|
// that name.
|
|
|
|
if (SP->getLinkageName() != "" && SP->getName() != SP->getLinkageName() &&
|
|
|
|
(useAllLinkageNames() || InfoHolder.getAbstractSPDies().lookup(SP)))
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelName(CU, SP->getLinkageName(), Die);
|
2011-11-10 19:25:34 +00:00
|
|
|
|
|
|
|
// If this is an Objective-C selector name add it to the ObjC accelerator
|
|
|
|
// too.
|
2015-04-14 03:40:37 +00:00
|
|
|
if (isObjCClass(SP->getName())) {
|
2011-11-10 19:25:34 +00:00
|
|
|
StringRef Class, Category;
|
2015-04-14 03:40:37 +00:00
|
|
|
getObjCClassCategory(SP->getName(), Class, Category);
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelObjC(CU, Class, Die);
|
2011-11-10 19:25:34 +00:00
|
|
|
if (Category != "")
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelObjC(CU, Category, Die);
|
2011-11-10 19:25:34 +00:00
|
|
|
// Also add the base method name to the name table.
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelName(CU, getObjCMethodName(SP->getName()), Die);
|
2011-11-10 19:25:34 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-11 19:40:28 +00:00
|
|
|
/// Check whether we should create a DIE for the given Scope, return true
|
|
|
|
/// if we don't create a DIE (the corresponding DIE is null).
|
2013-09-10 18:40:41 +00:00
|
|
|
bool DwarfDebug::isLexicalScopeDIENull(LexicalScope *Scope) {
|
|
|
|
if (Scope->isAbstractScope())
|
|
|
|
return false;
|
|
|
|
|
2013-09-11 19:40:28 +00:00
|
|
|
// We don't create a DIE if there is no Range.
|
2013-09-10 18:40:41 +00:00
|
|
|
const SmallVectorImpl<InsnRange> &Ranges = Scope->getRanges();
|
|
|
|
if (Ranges.empty())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (Ranges.size() > 1)
|
|
|
|
return false;
|
|
|
|
|
2013-09-11 19:40:28 +00:00
|
|
|
// We don't create a DIE if we have a single Range and the end label
|
|
|
|
// is null.
|
2014-08-31 02:14:26 +00:00
|
|
|
return !getLabelAfterInsn(Ranges.front().second);
|
2013-09-10 18:40:41 +00:00
|
|
|
}
|
|
|
|
|
2016-08-06 11:13:10 +00:00
|
|
|
template <typename Func> static void forBothCUs(DwarfCompileUnit &CU, Func F) {
|
Provide gmlt-like inline scope information in the skeleton CU to facilitate symbolication without needing the .dwo files
Clang -gsplit-dwarf self-host -O0, binary increases by 0.0005%, -O2,
binary increases by 25%.
A large binary inside Google, split-dwarf, -O0, and other internal flags
(GDB index, etc) increases by 1.8%, optimized build is 35%.
The size impact may be somewhat greater in .o files (I haven't measured
that much - since the linked executable -O0 numbers seemed low enough)
due to relocations. These relocations could be removed if we taught the
llvm-symbolizer to handle indexed addressing in the .o file (GDB can't
cope with this just yet, but GDB won't be reading this info anyway).
Also debug_ranges could be shared between .o and .dwo, though ideally
debug_ranges would get a schema that could used index(+offset)
addressing, and move to the .dwo file, then we'd be back to sharing
addresses in the address pool again.
But for now, these sizes seem small enough to go ahead with this.
Verified that no other DW_TAGs are produced into the .o file other than
subprograms and inlined_subroutines.
llvm-svn: 221306
2014-11-04 22:12:25 +00:00
|
|
|
F(CU);
|
|
|
|
if (auto *SkelCU = CU.getSkeleton())
|
2016-08-24 18:29:49 +00:00
|
|
|
if (CU.getCUNode()->getSplitDebugInlining())
|
|
|
|
F(*SkelCU);
|
Provide gmlt-like inline scope information in the skeleton CU to facilitate symbolication without needing the .dwo files
Clang -gsplit-dwarf self-host -O0, binary increases by 0.0005%, -O2,
binary increases by 25%.
A large binary inside Google, split-dwarf, -O0, and other internal flags
(GDB index, etc) increases by 1.8%, optimized build is 35%.
The size impact may be somewhat greater in .o files (I haven't measured
that much - since the linked executable -O0 numbers seemed low enough)
due to relocations. These relocations could be removed if we taught the
llvm-symbolizer to handle indexed addressing in the .o file (GDB can't
cope with this just yet, but GDB won't be reading this info anyway).
Also debug_ranges could be shared between .o and .dwo, though ideally
debug_ranges would get a schema that could used index(+offset)
addressing, and move to the .dwo file, then we'd be back to sharing
addresses in the address pool again.
But for now, these sizes seem small enough to go ahead with this.
Verified that no other DW_TAGs are produced into the .o file other than
subprograms and inlined_subroutines.
llvm-svn: 221306
2014-11-04 22:12:25 +00:00
|
|
|
}
|
|
|
|
|
2017-05-12 01:13:45 +00:00
|
|
|
bool DwarfDebug::shareAcrossDWOCUs() const {
|
|
|
|
return SplitDwarfCrossCuReferences;
|
|
|
|
}
|
|
|
|
|
|
|
|
void DwarfDebug::constructAbstractSubprogramScopeDIE(DwarfCompileUnit &SrcCU,
|
|
|
|
LexicalScope *Scope) {
|
2014-04-28 20:27:02 +00:00
|
|
|
assert(Scope && Scope->getScopeNode());
|
2014-04-29 15:58:35 +00:00
|
|
|
assert(Scope->isAbstractScope());
|
|
|
|
assert(!Scope->getInlinedAt());
|
2014-04-28 20:27:02 +00:00
|
|
|
|
2016-12-14 19:38:39 +00:00
|
|
|
auto *SP = cast<DISubprogram>(Scope->getScopeNode());
|
2014-04-29 15:58:35 +00:00
|
|
|
|
2014-05-21 23:14:12 +00:00
|
|
|
// Find the subprogram's DwarfCompileUnit in the SPMap in case the subprogram
|
|
|
|
// was inlined from another compile unit.
|
2017-05-29 06:25:30 +00:00
|
|
|
if (useSplitDwarf() && !shareAcrossDWOCUs() && !SP->getUnit()->getSplitDebugInlining())
|
|
|
|
// Avoid building the original CU if it won't be used
|
|
|
|
SrcCU.constructAbstractSubprogramScopeDIE(Scope);
|
|
|
|
else {
|
|
|
|
auto &CU = getOrCreateDwarfCompileUnit(SP->getUnit());
|
|
|
|
if (auto *SkelCU = CU.getSkeleton()) {
|
|
|
|
(shareAcrossDWOCUs() ? CU : SrcCU)
|
|
|
|
.constructAbstractSubprogramScopeDIE(Scope);
|
|
|
|
if (CU.getCUNode()->getSplitDebugInlining())
|
|
|
|
SkelCU->constructAbstractSubprogramScopeDIE(Scope);
|
|
|
|
} else
|
|
|
|
CU.constructAbstractSubprogramScopeDIE(Scope);
|
2017-05-12 01:13:45 +00:00
|
|
|
}
|
2014-04-29 15:58:35 +00:00
|
|
|
}
|
2014-04-28 20:27:02 +00:00
|
|
|
|
Reland (again): [DWARF] Allow cross-CU references of subprogram definitions
This is a revert-of-revert (i.e. this reverts commit 802bec89, which
itself reverted fa4701e1 and 79daafc9) with a fix folded in. The problem
was that call site tags weren't emitted properly when LTO was enabled
along with split-dwarf. This required a minor fix. I've added a reduced
test case in test/DebugInfo/X86/fission-call-site.ll.
Original commit message:
This allows a call site tag in CU A to reference a callee DIE in CU B
without resorting to creating an incomplete duplicate DIE for the callee
inside of CU A.
We already allow cross-CU references of subprogram declarations, so it
doesn't seem like definitions ought to be special.
This improves entry value evaluation and tail call frame synthesis in
the LTO setting. During LTO, it's common for cross-module inlining to
produce a call in some CU A where the callee resides in a different CU,
and there is no declaration subprogram for the callee anywhere. In this
case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram
in order to fill in the call site tag. That empty 'definition' defeats
entry value evaluation etc., because the debugger can't figure out what
it means.
As a follow-up, maybe we could add a DWARF verifier check that a
DW_TAG_subprogram at least has a DW_AT_name attribute.
Update #1:
Reland with a fix to create a declaration DIE when the declaration is
missing from the CU's retainedTypes list. The declaration is left out
of the retainedTypes list in two cases:
1) Re-compiling pre-r266445 bitcode (in which declarations weren't added
to the retainedTypes list), and
2) Doing LTO function importing (which doesn't update the retainedTypes
list).
It's possible to handle (1) and (2) by modifying the retainedTypes list
(in AutoUpgrade, or in the LTO importing logic resp.), but I don't see
an advantage to doing it this way, as it would cause more DWARF to be
emitted compared to creating the declaration DIEs lazily.
Update #2:
Fold in a fix for call site tag emission in the split-dwarf + LTO case.
Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a
ReleaseLTO-g build of the test suite.
rdar://46577651, rdar://57855316, rdar://57840415, rdar://58888440
Differential Revision: https://reviews.llvm.org/D70350
2020-01-25 12:52:47 -08:00
|
|
|
DIE &DwarfDebug::constructSubprogramDefinitionDIE(const DISubprogram *SP) {
|
|
|
|
DICompileUnit *Unit = SP->getUnit();
|
|
|
|
assert(SP->isDefinition() && "Subprogram not a definition");
|
|
|
|
assert(Unit && "Subprogram definition without parent unit");
|
|
|
|
auto &CU = getOrCreateDwarfCompileUnit(Unit);
|
|
|
|
return *CU.getOrCreateSubprogramDIE(SP);
|
|
|
|
}
|
|
|
|
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
/// Represents a parameter whose call site value can be described by applying a
|
|
|
|
/// debug expression to a register in the forwarded register worklist.
|
|
|
|
struct FwdRegParamInfo {
|
|
|
|
/// The described parameter register.
|
|
|
|
unsigned ParamReg;
|
|
|
|
|
|
|
|
/// Debug expression that has been built up when walking through the
|
|
|
|
/// instruction chain that produces the parameter's value.
|
|
|
|
const DIExpression *Expr;
|
|
|
|
};
|
|
|
|
|
2020-02-27 09:53:31 +01:00
|
|
|
/// Register worklist for finding call site values.
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
using FwdRegWorklist = MapVector<unsigned, SmallVector<FwdRegParamInfo, 2>>;
|
2020-02-27 09:53:31 +01:00
|
|
|
|
2020-03-20 11:12:01 -07:00
|
|
|
/// Append the expression \p Addition to \p Original and return the result.
|
|
|
|
static const DIExpression *combineDIExpressions(const DIExpression *Original,
|
|
|
|
const DIExpression *Addition) {
|
|
|
|
std::vector<uint64_t> Elts = Addition->getElements().vec();
|
|
|
|
// Avoid multiple DW_OP_stack_values.
|
|
|
|
if (Original->isImplicit() && Addition->isImplicit())
|
|
|
|
erase_if(Elts, [](uint64_t Op) { return Op == dwarf::DW_OP_stack_value; });
|
|
|
|
const DIExpression *CombinedExpr =
|
|
|
|
(Elts.size() > 0) ? DIExpression::append(Original, Elts) : Original;
|
|
|
|
return CombinedExpr;
|
|
|
|
}
|
|
|
|
|
2020-02-27 09:53:31 +01:00
|
|
|
/// Emit call site parameter entries that are described by the given value and
|
|
|
|
/// debug expression.
|
|
|
|
template <typename ValT>
|
|
|
|
static void finishCallSiteParams(ValT Val, const DIExpression *Expr,
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
ArrayRef<FwdRegParamInfo> DescribedParams,
|
2020-02-27 09:53:31 +01:00
|
|
|
ParamSet &Params) {
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
for (auto Param : DescribedParams) {
|
|
|
|
bool ShouldCombineExpressions = Expr && Param.Expr->getNumElements() > 0;
|
|
|
|
|
|
|
|
// TODO: Entry value operations can currently not be combined with any
|
|
|
|
// other expressions, so we can't emit call site entries in those cases.
|
|
|
|
if (ShouldCombineExpressions && Expr->isEntryValue())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// If a parameter's call site value is produced by a chain of
|
|
|
|
// instructions we may have already created an expression for the
|
|
|
|
// parameter when walking through the instructions. Append that to the
|
|
|
|
// base expression.
|
|
|
|
const DIExpression *CombinedExpr =
|
2020-03-20 11:12:01 -07:00
|
|
|
ShouldCombineExpressions ? combineDIExpressions(Expr, Param.Expr)
|
|
|
|
: Expr;
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
assert((!CombinedExpr || CombinedExpr->isValid()) &&
|
|
|
|
"Combined debug expression is invalid");
|
|
|
|
|
|
|
|
DbgValueLoc DbgLocVal(CombinedExpr, Val);
|
|
|
|
DbgCallSiteParam CSParm(Param.ParamReg, DbgLocVal);
|
2020-02-27 09:53:31 +01:00
|
|
|
Params.push_back(CSParm);
|
|
|
|
++NumCSParams;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Add \p Reg to the worklist, if it's not already present, and mark that the
|
|
|
|
/// given parameter registers' values can (potentially) be described using
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
/// that register and an debug expression.
|
2020-02-27 09:53:31 +01:00
|
|
|
static void addToFwdRegWorklist(FwdRegWorklist &Worklist, unsigned Reg,
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
const DIExpression *Expr,
|
|
|
|
ArrayRef<FwdRegParamInfo> ParamsToAdd) {
|
2020-02-27 09:53:31 +01:00
|
|
|
auto I = Worklist.insert({Reg, {}});
|
|
|
|
auto &ParamsForFwdReg = I.first->second;
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
for (auto Param : ParamsToAdd) {
|
|
|
|
assert(none_of(ParamsForFwdReg,
|
|
|
|
[Param](const FwdRegParamInfo &D) {
|
|
|
|
return D.ParamReg == Param.ParamReg;
|
|
|
|
}) &&
|
2020-02-27 09:53:31 +01:00
|
|
|
"Same parameter described twice by forwarding reg");
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
|
|
|
|
// If a parameter's call site value is produced by a chain of
|
|
|
|
// instructions we may have already created an expression for the
|
|
|
|
// parameter when walking through the instructions. Append that to the
|
|
|
|
// new expression.
|
2020-03-20 11:12:01 -07:00
|
|
|
const DIExpression *CombinedExpr = combineDIExpressions(Expr, Param.Expr);
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
ParamsForFwdReg.push_back({Param.ParamReg, CombinedExpr});
|
2020-02-27 09:53:31 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-07-31 16:51:28 +00:00
|
|
|
/// Try to interpret values loaded into registers that forward parameters
|
|
|
|
/// for \p CallMI. Store parameters with interpreted value into \p Params.
|
|
|
|
static void collectCallSiteParameters(const MachineInstr *CallMI,
|
|
|
|
ParamSet &Params) {
|
|
|
|
auto *MF = CallMI->getMF();
|
|
|
|
auto CalleesMap = MF->getCallSitesInfo();
|
|
|
|
auto CallFwdRegsInfo = CalleesMap.find(CallMI);
|
|
|
|
|
|
|
|
// There is no information for the call instruction.
|
|
|
|
if (CallFwdRegsInfo == CalleesMap.end())
|
|
|
|
return;
|
|
|
|
|
|
|
|
auto *MBB = CallMI->getParent();
|
2020-05-12 11:39:01 -07:00
|
|
|
const auto &TRI = *MF->getSubtarget().getRegisterInfo();
|
|
|
|
const auto &TII = *MF->getSubtarget().getInstrInfo();
|
|
|
|
const auto &TLI = *MF->getSubtarget().getTargetLowering();
|
2019-07-31 16:51:28 +00:00
|
|
|
|
|
|
|
// Skip the call instruction.
|
|
|
|
auto I = std::next(CallMI->getReverseIterator());
|
|
|
|
|
2020-01-27 11:36:03 +01:00
|
|
|
FwdRegWorklist ForwardedRegWorklist;
|
|
|
|
|
|
|
|
// If an instruction defines more than one item in the worklist, we may run
|
|
|
|
// into situations where a worklist register's value is (potentially)
|
|
|
|
// described by the previous value of another register that is also defined
|
|
|
|
// by that instruction.
|
|
|
|
//
|
|
|
|
// This can for example occur in cases like this:
|
|
|
|
//
|
|
|
|
// $r1 = mov 123
|
|
|
|
// $r0, $r1 = mvrr $r1, 456
|
|
|
|
// call @foo, $r0, $r1
|
|
|
|
//
|
|
|
|
// When describing $r1's value for the mvrr instruction, we need to make sure
|
|
|
|
// that we don't finalize an entry value for $r0, as that is dependent on the
|
|
|
|
// previous value of $r1 (123 rather than 456).
|
|
|
|
//
|
|
|
|
// In order to not have to distinguish between those cases when finalizing
|
|
|
|
// entry values, we simply postpone adding new parameter registers to the
|
|
|
|
// worklist, by first keeping them in this temporary container until the
|
|
|
|
// instruction has been handled.
|
|
|
|
FwdRegWorklist NewWorklistItems;
|
|
|
|
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
const DIExpression *EmptyExpr =
|
|
|
|
DIExpression::get(MF->getFunction().getContext(), {});
|
|
|
|
|
2019-07-31 16:51:28 +00:00
|
|
|
// Add all the forwarding registers into the ForwardedRegWorklist.
|
|
|
|
for (auto ArgReg : CallFwdRegsInfo->second) {
|
2020-01-27 11:36:03 +01:00
|
|
|
bool InsertedReg =
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
ForwardedRegWorklist.insert({ArgReg.Reg, {{ArgReg.Reg, EmptyExpr}}})
|
|
|
|
.second;
|
2019-07-31 16:51:28 +00:00
|
|
|
assert(InsertedReg && "Single register used to forward two arguments?");
|
2019-07-31 21:02:03 +00:00
|
|
|
(void)InsertedReg;
|
2019-07-31 16:51:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// We erase, from the ForwardedRegWorklist, those forwarding registers for
|
|
|
|
// which we successfully describe a loaded value (by using
|
|
|
|
// the describeLoadedValue()). For those remaining arguments in the working
|
|
|
|
// list, for which we do not describe a loaded value by
|
|
|
|
// the describeLoadedValue(), we try to generate an entry value expression
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
// for their call site value description, if the call is within the entry MBB.
|
2019-07-31 16:51:28 +00:00
|
|
|
// TODO: Handle situations when call site parameter value can be described
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
// as the entry value within basic blocks other than the first one.
|
2019-07-31 16:51:28 +00:00
|
|
|
bool ShouldTryEmitEntryVals = MBB->getIterator() == MF->begin();
|
|
|
|
|
[DebugInfo][X86] Describe call site values for zero-valued imms
Summary:
Add zero-materializing XORs to X86's describeLoadedValue() hook in order
to produce call site values.
I have had to change the defs logic in collectCallSiteParameters() a bit
to be able to describe the XORs. The XORs implicitly define $eflags,
which would cause them to never be considered, due to a guard condition
that I->getNumDefs() is one. I have changed that condition so that we
now only consider instructions where a forwarded register overlaps with
the instruction's single explicit define. We still need to collect the implicit
defines of other forwarded registers to remove them from the work list.
I'm not sure how to move towards supporting instructions with multiple
explicit defines, cases where forwarded register are implicitly defined,
and/or cases where an instruction produces values for multiple forwarded
registers. Perhaps the describeLoadedValue() hook should take a register
argument, and we then leave it up to the hook to describe the loaded
value in that register? I have not yet encountered a situation where
that would be necessary though.
Reviewers: aprantl, vsk, djtodoro, NikolaPrica
Reviewed By: vsk
Subscribers: ychen, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67225
llvm-svn: 371333
2019-09-08 14:22:06 +00:00
|
|
|
// If the MI is an instruction defining one or more parameters' forwarding
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
// registers, add those defines.
|
2020-05-12 09:04:57 +02:00
|
|
|
auto getForwardingRegsDefinedByMI = [&](const MachineInstr &MI,
|
|
|
|
SmallSetVector<unsigned, 4> &Defs) {
|
|
|
|
if (MI.isDebugInstr())
|
|
|
|
return;
|
|
|
|
|
|
|
|
for (const MachineOperand &MO : MI.operands()) {
|
|
|
|
if (MO.isReg() && MO.isDef() &&
|
|
|
|
Register::isPhysicalRegister(MO.getReg())) {
|
|
|
|
for (auto FwdReg : ForwardedRegWorklist)
|
2020-05-12 11:39:01 -07:00
|
|
|
if (TRI.regsOverlap(FwdReg.first, MO.getReg()))
|
2020-05-12 09:04:57 +02:00
|
|
|
Defs.insert(FwdReg.first);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
2019-07-31 16:51:28 +00:00
|
|
|
|
2019-11-13 18:06:16 +01:00
|
|
|
// Search for a loading value in forwarding registers.
|
2019-07-31 16:51:28 +00:00
|
|
|
for (; I != MBB->rend(); ++I) {
|
[DebugInfo] Handle call site values for instructions before call bundle
Summary:
If a call is bundled then the code that looks for instructions that
produce parameter values would break when reaching the call's bundle
header, due to the `ifCall(/*AnyInBundle*/)` invocation returning true.
It is not enough to simply ignore bundle headers in the `isCall()`
invocation, as the bundle header may have defines of parameter registers
due to the call, meaning that such registers would incorrectly be
removed from the worklist. Therefore, do not look at bundle headers at
all.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: aprantl, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D71024
2019-12-05 10:49:41 +01:00
|
|
|
// Skip bundle headers.
|
|
|
|
if (I->isBundle())
|
|
|
|
continue;
|
|
|
|
|
2019-07-31 16:51:28 +00:00
|
|
|
// If the next instruction is a call we can not interpret parameter's
|
|
|
|
// forwarding registers or we finished the interpretation of all parameters.
|
|
|
|
if (I->isCall())
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (ForwardedRegWorklist.empty())
|
|
|
|
return;
|
|
|
|
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
// Set of worklist registers that are defined by this instruction.
|
|
|
|
SmallSetVector<unsigned, 4> FwdRegDefs;
|
|
|
|
|
2020-05-12 09:04:57 +02:00
|
|
|
getForwardingRegsDefinedByMI(*I, FwdRegDefs);
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
if (FwdRegDefs.empty())
|
2019-07-31 16:51:28 +00:00
|
|
|
continue;
|
|
|
|
|
Don't separate imp/expl def handling for call site params
Summary:
Since D70431 the describeLoadedValue() hook takes a parameter register,
meaning that it can now be asked to describe any register. This means
that we can drop the difference between explicit and implicit defines
that we previously had in collectCallSiteParameters().
I have not found any case for any upstream targets where a parameter
register is only implicitly defined, and does not overlap with any
explicit defines. I don't know if such a case would even make sense. So
as far as I have tested, this patch should be a non-functional change.
However, this reduces the complexity of the code a bit, and it will
simplify the implementation of an upcoming patch which solves PR44118.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D73167
2020-01-27 11:15:55 +01:00
|
|
|
for (auto ParamFwdReg : FwdRegDefs) {
|
2020-05-12 11:39:01 -07:00
|
|
|
if (auto ParamValue = TII.describeLoadedValue(*I, ParamFwdReg)) {
|
[DebugInfo] Make describeLoadedValue() reg aware
Summary:
Currently the describeLoadedValue() hook is assumed to describe the
value of the instruction's first explicit define. The hook will not be
called for instructions with more than one explicit define.
This commit adds a register parameter to the describeLoadedValue() hook,
and invokes the hook for all registers in the worklist.
This will allow us to for example describe instructions which produce
more than two parameters' values; e.g. Hexagon's various combine
instructions.
This also fixes situations in our downstream target where we may pass
smaller parameters in the high part of a register. If such a parameter's
value is produced by a larger copy instruction, we can't describe the
call site value using the super-register, and we instead need to know
which sub-register that should be used.
This also allows us to handle cases like this:
$ebx = [...]
$rdi = MOVSX64rr32 $ebx
$esi = MOV32rr $edi
CALL64pcrel32 @call
The hook will first be invoked for the MOV32rr instruction, which will
say that @call's second parameter (passed in $esi) is described by $edi.
As $edi is not preserved it will be added to the worklist. When we get
to the MOVSX64rr32 instruction, we need to describe two values; the
sign-extended value of $ebx -> $rdi for the first parameter, and $ebx ->
$edi for the second parameter, which is now possible.
This commit modifies the dbgcall-site-lea-interpretation.mir test case.
In the test case, the values of some 32-bit parameters were produced
with LEA64r. Perhaps we can in general cases handle such by emitting
expressions that AND out the lower 32-bits, but I have not been able to
land in a case where a LEA64r is used for a 32-bit parameter instead of
LEA64_32 from C code.
I have not found a case where it would be useful to describe parameters
using implicit defines, so in this patch the hook is still only invoked
for explicit defines of forwarding registers.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: ormris, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D70431
2019-12-09 10:46:16 +01:00
|
|
|
if (ParamValue->first.isImm()) {
|
|
|
|
int64_t Val = ParamValue->first.getImm();
|
2020-02-27 09:53:31 +01:00
|
|
|
finishCallSiteParams(Val, ParamValue->second,
|
|
|
|
ForwardedRegWorklist[ParamFwdReg], Params);
|
[DebugInfo] Make describeLoadedValue() reg aware
Summary:
Currently the describeLoadedValue() hook is assumed to describe the
value of the instruction's first explicit define. The hook will not be
called for instructions with more than one explicit define.
This commit adds a register parameter to the describeLoadedValue() hook,
and invokes the hook for all registers in the worklist.
This will allow us to for example describe instructions which produce
more than two parameters' values; e.g. Hexagon's various combine
instructions.
This also fixes situations in our downstream target where we may pass
smaller parameters in the high part of a register. If such a parameter's
value is produced by a larger copy instruction, we can't describe the
call site value using the super-register, and we instead need to know
which sub-register that should be used.
This also allows us to handle cases like this:
$ebx = [...]
$rdi = MOVSX64rr32 $ebx
$esi = MOV32rr $edi
CALL64pcrel32 @call
The hook will first be invoked for the MOV32rr instruction, which will
say that @call's second parameter (passed in $esi) is described by $edi.
As $edi is not preserved it will be added to the worklist. When we get
to the MOVSX64rr32 instruction, we need to describe two values; the
sign-extended value of $ebx -> $rdi for the first parameter, and $ebx ->
$edi for the second parameter, which is now possible.
This commit modifies the dbgcall-site-lea-interpretation.mir test case.
In the test case, the values of some 32-bit parameters were produced
with LEA64r. Perhaps we can in general cases handle such by emitting
expressions that AND out the lower 32-bits, but I have not been able to
land in a case where a LEA64r is used for a 32-bit parameter instead of
LEA64_32 from C code.
I have not found a case where it would be useful to describe parameters
using implicit defines, so in this patch the hook is still only invoked
for explicit defines of forwarding registers.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: ormris, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D70431
2019-12-09 10:46:16 +01:00
|
|
|
} else if (ParamValue->first.isReg()) {
|
|
|
|
Register RegLoc = ParamValue->first.getReg();
|
2020-05-12 11:39:01 -07:00
|
|
|
unsigned SP = TLI.getStackPointerRegisterToSaveRestore();
|
|
|
|
Register FP = TRI.getFrameRegister(*MF);
|
[DebugInfo] Make describeLoadedValue() reg aware
Summary:
Currently the describeLoadedValue() hook is assumed to describe the
value of the instruction's first explicit define. The hook will not be
called for instructions with more than one explicit define.
This commit adds a register parameter to the describeLoadedValue() hook,
and invokes the hook for all registers in the worklist.
This will allow us to for example describe instructions which produce
more than two parameters' values; e.g. Hexagon's various combine
instructions.
This also fixes situations in our downstream target where we may pass
smaller parameters in the high part of a register. If such a parameter's
value is produced by a larger copy instruction, we can't describe the
call site value using the super-register, and we instead need to know
which sub-register that should be used.
This also allows us to handle cases like this:
$ebx = [...]
$rdi = MOVSX64rr32 $ebx
$esi = MOV32rr $edi
CALL64pcrel32 @call
The hook will first be invoked for the MOV32rr instruction, which will
say that @call's second parameter (passed in $esi) is described by $edi.
As $edi is not preserved it will be added to the worklist. When we get
to the MOVSX64rr32 instruction, we need to describe two values; the
sign-extended value of $ebx -> $rdi for the first parameter, and $ebx ->
$edi for the second parameter, which is now possible.
This commit modifies the dbgcall-site-lea-interpretation.mir test case.
In the test case, the values of some 32-bit parameters were produced
with LEA64r. Perhaps we can in general cases handle such by emitting
expressions that AND out the lower 32-bits, but I have not been able to
land in a case where a LEA64r is used for a 32-bit parameter instead of
LEA64_32 from C code.
I have not found a case where it would be useful to describe parameters
using implicit defines, so in this patch the hook is still only invoked
for explicit defines of forwarding registers.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: ormris, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D70431
2019-12-09 10:46:16 +01:00
|
|
|
bool IsSPorFP = (RegLoc == SP) || (RegLoc == FP);
|
2020-05-12 11:39:01 -07:00
|
|
|
if (TRI.isCalleeSavedPhysReg(RegLoc, *MF) || IsSPorFP) {
|
2020-02-27 09:53:31 +01:00
|
|
|
MachineLocation MLoc(RegLoc, /*IsIndirect=*/IsSPorFP);
|
|
|
|
finishCallSiteParams(MLoc, ParamValue->second,
|
|
|
|
ForwardedRegWorklist[ParamFwdReg], Params);
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
} else {
|
2020-01-27 11:36:03 +01:00
|
|
|
// ParamFwdReg was described by the non-callee saved register
|
|
|
|
// RegLoc. Mark that the call site values for the parameters are
|
|
|
|
// dependent on that register instead of ParamFwdReg. Since RegLoc
|
|
|
|
// may be a register that will be handled in this iteration, we
|
|
|
|
// postpone adding the items to the worklist, and instead keep them
|
|
|
|
// in a temporary container.
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
addToFwdRegWorklist(NewWorklistItems, RegLoc, ParamValue->second,
|
2020-02-27 09:53:31 +01:00
|
|
|
ForwardedRegWorklist[ParamFwdReg]);
|
[DebugInfo] Make describeLoadedValue() reg aware
Summary:
Currently the describeLoadedValue() hook is assumed to describe the
value of the instruction's first explicit define. The hook will not be
called for instructions with more than one explicit define.
This commit adds a register parameter to the describeLoadedValue() hook,
and invokes the hook for all registers in the worklist.
This will allow us to for example describe instructions which produce
more than two parameters' values; e.g. Hexagon's various combine
instructions.
This also fixes situations in our downstream target where we may pass
smaller parameters in the high part of a register. If such a parameter's
value is produced by a larger copy instruction, we can't describe the
call site value using the super-register, and we instead need to know
which sub-register that should be used.
This also allows us to handle cases like this:
$ebx = [...]
$rdi = MOVSX64rr32 $ebx
$esi = MOV32rr $edi
CALL64pcrel32 @call
The hook will first be invoked for the MOV32rr instruction, which will
say that @call's second parameter (passed in $esi) is described by $edi.
As $edi is not preserved it will be added to the worklist. When we get
to the MOVSX64rr32 instruction, we need to describe two values; the
sign-extended value of $ebx -> $rdi for the first parameter, and $ebx ->
$edi for the second parameter, which is now possible.
This commit modifies the dbgcall-site-lea-interpretation.mir test case.
In the test case, the values of some 32-bit parameters were produced
with LEA64r. Perhaps we can in general cases handle such by emitting
expressions that AND out the lower 32-bits, but I have not been able to
land in a case where a LEA64r is used for a 32-bit parameter instead of
LEA64_32 from C code.
I have not found a case where it would be useful to describe parameters
using implicit defines, so in this patch the hook is still only invoked
for explicit defines of forwarding registers.
Reviewers: djtodoro, NikolaPrica, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: ormris, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D70431
2019-12-09 10:46:16 +01:00
|
|
|
}
|
2019-07-31 16:51:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2020-01-27 11:36:03 +01:00
|
|
|
|
|
|
|
// Remove all registers that this instruction defines from the worklist.
|
|
|
|
for (auto ParamFwdReg : FwdRegDefs)
|
|
|
|
ForwardedRegWorklist.erase(ParamFwdReg);
|
|
|
|
|
|
|
|
// Now that we are done handling this instruction, add items from the
|
|
|
|
// temporary worklist to the real one.
|
|
|
|
for (auto New : NewWorklistItems)
|
[DebugInfo] Describe call site values for chains of expression producing instrs
Summary:
If the describeLoadedValue() hook produced a DIExpression when
describing a instruction, and it was not possible to emit a call site
entry directly (the value operand was not an immediate nor a preserved
register), then that described value could not be inserted into the
worklist, and would instead be dropped, meaning that the parameter's
call site value couldn't be described.
This patch extends the worklist so that each entry has an DIExpression
that is built up when iterating through the instructions.
This allows us to describe instruction chains like this:
$reg0 = mv $fp
$reg0 = add $reg0, offset
call @call_with_offseted_fp
Since DW_OP_LLVM_entry_value operations can't be combined with any other
expression, such call site entries will not be emitted. I have added a
test, dbgcall-site-expr-entry-value.mir, which verifies that we don't
assert or emit broken DWARF in such cases.
Reviewers: djtodoro, aprantl, vsk
Reviewed By: djtodoro, vsk
Subscribers: hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D75036
2020-02-27 09:54:37 +01:00
|
|
|
addToFwdRegWorklist(ForwardedRegWorklist, New.first, EmptyExpr,
|
|
|
|
New.second);
|
2020-01-27 11:36:03 +01:00
|
|
|
NewWorklistItems.clear();
|
2019-07-31 16:51:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Emit the call site parameter's value as an entry value.
|
|
|
|
if (ShouldTryEmitEntryVals) {
|
[DebugInfo] Add a DW_OP_LLVM_entry_value operation
Summary:
Internally in LLVM's metadata we use DW_OP_entry_value operations with
the same semantics as DWARF; that is, its operand specifies the number
of bytes that the entry value covers.
At the time of emitting entry values we don't know the emitted size of
the DWARF expression that the entry value will cover. Currently the size
is hardcoded to 1 in DIExpression, and other values causes the verifier
to fail. As the size is 1, that effectively means that we can only have
valid entry values for registers that can be encoded in one byte, which
are the registers with DWARF numbers 0 to 31 (as they can be encoded as
single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte
DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump
will print an operation "correctly", even if the byte size is less than
that, which may make it seem that we emit correct DWARF for registers
with DWARF numbers > 31. If you instead use readelf for such cases, it
will interpret the number of specified bytes as a DWARF expression. This
seems like a limitation in llvm-dwarfdump.
As suggested in D66746, a way forward would be to add an internal
variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand
instead specifies the number of operations that the entry value covers,
and we then translate that into the byte size at the time of emission.
In this patch that internal operation is added. This patch keeps the
limitation that a entry value can only be applied to simple register
locations, but it will fix the issue with the size operand being
incorrect for DWARF numbers > 31.
Reviewers: aprantl, vsk, djtodoro, NikolaPrica
Reviewed By: aprantl
Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67492
llvm-svn: 374881
2019-10-15 11:31:21 +00:00
|
|
|
// Create an expression where the register's entry value is used.
|
|
|
|
DIExpression *EntryExpr = DIExpression::get(
|
|
|
|
MF->getFunction().getContext(), {dwarf::DW_OP_LLVM_entry_value, 1});
|
2019-07-31 16:51:28 +00:00
|
|
|
for (auto RegEntry : ForwardedRegWorklist) {
|
2020-02-27 09:53:31 +01:00
|
|
|
MachineLocation MLoc(RegEntry.first);
|
|
|
|
finishCallSiteParams(MLoc, EntryExpr, RegEntry.second, Params);
|
2019-07-31 16:51:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-10-05 20:37:17 +00:00
|
|
|
void DwarfDebug::constructCallSiteEntryDIEs(const DISubprogram &SP,
|
|
|
|
DwarfCompileUnit &CU, DIE &ScopeDIE,
|
|
|
|
const MachineFunction &MF) {
|
|
|
|
// Add a call site-related attribute (DWARF5, Sec. 3.3.1.3). Do this only if
|
|
|
|
// the subprogram is required to have one.
|
|
|
|
if (!SP.areAllCallsDescribed() || !SP.isDefinition())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Use DW_AT_call_all_calls to express that call site entries are present
|
|
|
|
// for both tail and non-tail calls. Don't use DW_AT_call_all_source_calls
|
|
|
|
// because one of its requirements is not met: call site entries for
|
|
|
|
// optimized-out calls are elided.
|
2019-08-26 20:53:34 +00:00
|
|
|
CU.addFlag(ScopeDIE, CU.getDwarf5OrGNUAttr(dwarf::DW_AT_call_all_calls));
|
2018-10-05 20:37:17 +00:00
|
|
|
|
|
|
|
const TargetInstrInfo *TII = MF.getSubtarget().getInstrInfo();
|
|
|
|
assert(TII && "TargetInstrInfo not found: cannot label tail calls");
|
|
|
|
|
|
|
|
// Emit call site entries for each call or tail call in the function.
|
|
|
|
for (const MachineBasicBlock &MBB : MF) {
|
|
|
|
for (const MachineInstr &MI : MBB.instrs()) {
|
2019-11-14 14:42:01 +00:00
|
|
|
// Bundles with call in them will pass the isCall() test below but do not
|
|
|
|
// have callee operand information so skip them here. Iterator will
|
|
|
|
// eventually reach the call MI.
|
|
|
|
if (MI.isBundle())
|
|
|
|
continue;
|
|
|
|
|
2018-10-05 20:37:17 +00:00
|
|
|
// Skip instructions which aren't calls. Both calls and tail-calling jump
|
|
|
|
// instructions (e.g TAILJMPd64) are classified correctly here.
|
2020-02-06 13:14:27 -08:00
|
|
|
if (!MI.isCandidateForCallSiteEntry())
|
2018-10-05 20:37:17 +00:00
|
|
|
continue;
|
|
|
|
|
2020-02-11 21:23:18 +00:00
|
|
|
// Skip instructions marked as frame setup, as they are not interesting to
|
|
|
|
// the user.
|
|
|
|
if (MI.getFlag(MachineInstr::FrameSetup))
|
|
|
|
continue;
|
|
|
|
|
2018-10-05 20:37:17 +00:00
|
|
|
// TODO: Add support for targets with delay slots (see: beginInstruction).
|
|
|
|
if (MI.hasDelaySlot())
|
|
|
|
return;
|
|
|
|
|
|
|
|
// If this is a direct call, find the callee's subprogram.
|
2019-07-31 16:51:28 +00:00
|
|
|
// In the case of an indirect call find the register that holds
|
|
|
|
// the callee.
|
2018-10-05 20:37:17 +00:00
|
|
|
const MachineOperand &CalleeOp = MI.getOperand(0);
|
2019-07-31 16:51:28 +00:00
|
|
|
if (!CalleeOp.isGlobal() && !CalleeOp.isReg())
|
2018-10-05 20:37:17 +00:00
|
|
|
continue;
|
2019-07-09 11:33:56 +00:00
|
|
|
|
2019-07-31 16:51:28 +00:00
|
|
|
unsigned CallReg = 0;
|
Reland (again): [DWARF] Allow cross-CU references of subprogram definitions
This is a revert-of-revert (i.e. this reverts commit 802bec89, which
itself reverted fa4701e1 and 79daafc9) with a fix folded in. The problem
was that call site tags weren't emitted properly when LTO was enabled
along with split-dwarf. This required a minor fix. I've added a reduced
test case in test/DebugInfo/X86/fission-call-site.ll.
Original commit message:
This allows a call site tag in CU A to reference a callee DIE in CU B
without resorting to creating an incomplete duplicate DIE for the callee
inside of CU A.
We already allow cross-CU references of subprogram declarations, so it
doesn't seem like definitions ought to be special.
This improves entry value evaluation and tail call frame synthesis in
the LTO setting. During LTO, it's common for cross-module inlining to
produce a call in some CU A where the callee resides in a different CU,
and there is no declaration subprogram for the callee anywhere. In this
case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram
in order to fill in the call site tag. That empty 'definition' defeats
entry value evaluation etc., because the debugger can't figure out what
it means.
As a follow-up, maybe we could add a DWARF verifier check that a
DW_TAG_subprogram at least has a DW_AT_name attribute.
Update #1:
Reland with a fix to create a declaration DIE when the declaration is
missing from the CU's retainedTypes list. The declaration is left out
of the retainedTypes list in two cases:
1) Re-compiling pre-r266445 bitcode (in which declarations weren't added
to the retainedTypes list), and
2) Doing LTO function importing (which doesn't update the retainedTypes
list).
It's possible to handle (1) and (2) by modifying the retainedTypes list
(in AutoUpgrade, or in the LTO importing logic resp.), but I don't see
an advantage to doing it this way, as it would cause more DWARF to be
emitted compared to creating the declaration DIEs lazily.
Update #2:
Fold in a fix for call site tag emission in the split-dwarf + LTO case.
Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a
ReleaseLTO-g build of the test suite.
rdar://46577651, rdar://57855316, rdar://57840415, rdar://58888440
Differential Revision: https://reviews.llvm.org/D70350
2020-01-25 12:52:47 -08:00
|
|
|
DIE *CalleeDIE = nullptr;
|
2019-07-31 16:51:28 +00:00
|
|
|
const Function *CalleeDecl = nullptr;
|
|
|
|
if (CalleeOp.isReg()) {
|
|
|
|
CallReg = CalleeOp.getReg();
|
|
|
|
if (!CallReg)
|
|
|
|
continue;
|
|
|
|
} else {
|
|
|
|
CalleeDecl = dyn_cast<Function>(CalleeOp.getGlobal());
|
|
|
|
if (!CalleeDecl || !CalleeDecl->getSubprogram())
|
|
|
|
continue;
|
Reland (again): [DWARF] Allow cross-CU references of subprogram definitions
This is a revert-of-revert (i.e. this reverts commit 802bec89, which
itself reverted fa4701e1 and 79daafc9) with a fix folded in. The problem
was that call site tags weren't emitted properly when LTO was enabled
along with split-dwarf. This required a minor fix. I've added a reduced
test case in test/DebugInfo/X86/fission-call-site.ll.
Original commit message:
This allows a call site tag in CU A to reference a callee DIE in CU B
without resorting to creating an incomplete duplicate DIE for the callee
inside of CU A.
We already allow cross-CU references of subprogram declarations, so it
doesn't seem like definitions ought to be special.
This improves entry value evaluation and tail call frame synthesis in
the LTO setting. During LTO, it's common for cross-module inlining to
produce a call in some CU A where the callee resides in a different CU,
and there is no declaration subprogram for the callee anywhere. In this
case llvm would (unnecessarily, I think) emit an empty DW_TAG_subprogram
in order to fill in the call site tag. That empty 'definition' defeats
entry value evaluation etc., because the debugger can't figure out what
it means.
As a follow-up, maybe we could add a DWARF verifier check that a
DW_TAG_subprogram at least has a DW_AT_name attribute.
Update #1:
Reland with a fix to create a declaration DIE when the declaration is
missing from the CU's retainedTypes list. The declaration is left out
of the retainedTypes list in two cases:
1) Re-compiling pre-r266445 bitcode (in which declarations weren't added
to the retainedTypes list), and
2) Doing LTO function importing (which doesn't update the retainedTypes
list).
It's possible to handle (1) and (2) by modifying the retainedTypes list
(in AutoUpgrade, or in the LTO importing logic resp.), but I don't see
an advantage to doing it this way, as it would cause more DWARF to be
emitted compared to creating the declaration DIEs lazily.
Update #2:
Fold in a fix for call site tag emission in the split-dwarf + LTO case.
Tested with a stage2 ThinLTO+RelWithDebInfo build of clang, and with a
ReleaseLTO-g build of the test suite.
rdar://46577651, rdar://57855316, rdar://57840415, rdar://58888440
Differential Revision: https://reviews.llvm.org/D70350
2020-01-25 12:52:47 -08:00
|
|
|
const DISubprogram *CalleeSP = CalleeDecl->getSubprogram();
|
|
|
|
|
|
|
|
if (CalleeSP->isDefinition()) {
|
|
|
|
// Ensure that a subprogram DIE for the callee is available in the
|
|
|
|
// appropriate CU.
|
|
|
|
CalleeDIE = &constructSubprogramDefinitionDIE(CalleeSP);
|
|
|
|
} else {
|
|
|
|
// Create the declaration DIE if it is missing. This is required to
|
|
|
|
// support compilation of old bitcode with an incomplete list of
|
|
|
|
// retained metadata.
|
|
|
|
CalleeDIE = CU.getOrCreateSubprogramDIE(CalleeSP);
|
|
|
|
}
|
|
|
|
assert(CalleeDIE && "Must have a DIE for the callee");
|
2019-07-31 16:51:28 +00:00
|
|
|
}
|
|
|
|
|
2018-10-05 20:37:17 +00:00
|
|
|
// TODO: Omit call site entries for runtime calls (objc_msgSend, etc).
|
|
|
|
|
|
|
|
bool IsTail = TII->isTailCall(MI);
|
|
|
|
|
2019-11-14 14:42:01 +00:00
|
|
|
// If MI is in a bundle, the label was created after the bundle since
|
|
|
|
// EmitFunctionBody iterates over top-level MIs. Get that top-level MI
|
|
|
|
// to search for that label below.
|
|
|
|
const MachineInstr *TopLevelCallMI =
|
|
|
|
MI.isInsideBundle() ? &*getBundleStart(MI.getIterator()) : &MI;
|
|
|
|
|
2020-03-17 17:56:28 -07:00
|
|
|
// For non-tail calls, the return PC is needed to disambiguate paths in
|
|
|
|
// the call graph which could lead to some target function. For tail
|
|
|
|
// calls, no return PC information is needed, unless tuning for GDB in
|
|
|
|
// DWARF4 mode in which case we fake a return PC for compatibility.
|
2020-01-09 18:00:33 -08:00
|
|
|
const MCSymbol *PCAddr =
|
2020-03-17 17:56:28 -07:00
|
|
|
(!IsTail || CU.useGNUAnalogForDwarf5Feature())
|
|
|
|
? const_cast<MCSymbol *>(getLabelAfterInsn(TopLevelCallMI))
|
|
|
|
: nullptr;
|
2019-07-31 16:51:28 +00:00
|
|
|
|
2020-03-17 17:56:28 -07:00
|
|
|
// For tail calls, it's necessary to record the address of the branch
|
|
|
|
// instruction so that the debugger can show where the tail call occurred.
|
|
|
|
const MCSymbol *CallAddr =
|
|
|
|
IsTail ? getLabelBeforeInsn(TopLevelCallMI) : nullptr;
|
|
|
|
|
|
|
|
assert((IsTail || PCAddr) && "Non-tail call without return PC");
|
2018-10-05 20:37:17 +00:00
|
|
|
|
|
|
|
LLVM_DEBUG(dbgs() << "CallSiteEntry: " << MF.getName() << " -> "
|
2019-07-31 16:51:28 +00:00
|
|
|
<< (CalleeDecl ? CalleeDecl->getName()
|
|
|
|
: StringRef(MF.getSubtarget()
|
|
|
|
.getRegisterInfo()
|
|
|
|
->getName(CallReg)))
|
|
|
|
<< (IsTail ? " [IsTail]" : "") << "\n");
|
|
|
|
|
2020-03-17 17:56:28 -07:00
|
|
|
DIE &CallSiteDIE = CU.constructCallSiteEntryDIE(
|
|
|
|
ScopeDIE, CalleeDIE, IsTail, PCAddr, CallAddr, CallReg);
|
2019-07-31 16:51:28 +00:00
|
|
|
|
2020-03-19 12:13:18 +01:00
|
|
|
// Optionally emit call-site-param debug info.
|
|
|
|
if (emitDebugEntryValues()) {
|
2019-07-31 16:51:28 +00:00
|
|
|
ParamSet Params;
|
|
|
|
// Try to interpret values of call site parameters.
|
|
|
|
collectCallSiteParameters(&MI, Params);
|
|
|
|
CU.constructCallSiteParmEntryDIEs(CallSiteDIE, Params);
|
|
|
|
}
|
2018-10-05 20:37:17 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-25 18:50:28 +00:00
|
|
|
void DwarfDebug::addGnuPubAttributes(DwarfCompileUnit &U, DIE &D) const {
|
2017-09-12 21:50:41 +00:00
|
|
|
if (!U.hasDwarfPubSections())
|
2013-12-04 21:31:26 +00:00
|
|
|
return;
|
|
|
|
|
2014-04-22 22:39:41 +00:00
|
|
|
U.addFlag(D, dwarf::DW_AT_GNU_pubnames);
|
2013-12-04 21:31:26 +00:00
|
|
|
}
|
|
|
|
|
2018-12-14 22:44:46 +00:00
|
|
|
void DwarfDebug::finishUnitAttributes(const DICompileUnit *DIUnit,
|
|
|
|
DwarfCompileUnit &NewCU) {
|
2014-04-28 21:04:29 +00:00
|
|
|
DIE &Die = NewCU.getUnitDie();
|
2018-12-14 22:44:46 +00:00
|
|
|
StringRef FN = DIUnit->getFilename();
|
2014-04-22 22:39:41 +00:00
|
|
|
|
2017-03-29 23:34:27 +00:00
|
|
|
StringRef Producer = DIUnit->getProducer();
|
|
|
|
StringRef Flags = DIUnit->getFlags();
|
2018-08-08 16:33:22 +00:00
|
|
|
if (!Flags.empty() && !useAppleExtensionAttributes()) {
|
2017-03-29 23:34:27 +00:00
|
|
|
std::string ProducerWithFlags = Producer.str() + " " + Flags.str();
|
|
|
|
NewCU.addString(Die, dwarf::DW_AT_producer, ProducerWithFlags);
|
|
|
|
} else
|
|
|
|
NewCU.addString(Die, dwarf::DW_AT_producer, Producer);
|
|
|
|
|
2014-04-28 21:04:29 +00:00
|
|
|
NewCU.addUInt(Die, dwarf::DW_AT_language, dwarf::DW_FORM_data2,
|
2015-04-15 23:19:27 +00:00
|
|
|
DIUnit->getSourceLanguage());
|
2014-04-28 21:04:29 +00:00
|
|
|
NewCU.addString(Die, dwarf::DW_AT_name, FN);
|
2020-01-14 13:37:04 -08:00
|
|
|
StringRef SysRoot = DIUnit->getSysRoot();
|
|
|
|
if (!SysRoot.empty())
|
|
|
|
NewCU.addString(Die, dwarf::DW_AT_LLVM_sysroot, SysRoot);
|
2020-03-04 14:12:54 -08:00
|
|
|
StringRef SDK = DIUnit->getSDK();
|
|
|
|
if (!SDK.empty())
|
|
|
|
NewCU.addString(Die, dwarf::DW_AT_APPLE_sdk, SDK);
|
2013-04-09 19:23:15 +00:00
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
// Add DW_str_offsets_base to the unit DIE, except for split units.
|
|
|
|
if (useSegmentedStringOffsetsTable() && !useSplitDwarf())
|
|
|
|
NewCU.addStringOffsetsStart();
|
|
|
|
|
2013-04-09 19:23:15 +00:00
|
|
|
if (!useSplitDwarf()) {
|
2015-03-10 16:58:10 +00:00
|
|
|
NewCU.initStmtList();
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2013-09-27 22:50:48 +00:00
|
|
|
// If we're using split dwarf the compilation dir is going to be in the
|
|
|
|
// skeleton CU and so we don't need to duplicate it here.
|
|
|
|
if (!CompilationDir.empty())
|
2014-04-28 21:04:29 +00:00
|
|
|
NewCU.addString(Die, dwarf::DW_AT_comp_dir, CompilationDir);
|
|
|
|
addGnuPubAttributes(NewCU, Die);
|
2013-09-27 22:50:48 +00:00
|
|
|
}
|
2013-09-13 00:35:05 +00:00
|
|
|
|
2016-05-24 21:19:28 +00:00
|
|
|
if (useAppleExtensionAttributes()) {
|
|
|
|
if (DIUnit->isOptimized())
|
|
|
|
NewCU.addFlag(Die, dwarf::DW_AT_APPLE_optimized);
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2016-05-24 21:19:28 +00:00
|
|
|
StringRef Flags = DIUnit->getFlags();
|
|
|
|
if (!Flags.empty())
|
|
|
|
NewCU.addString(Die, dwarf::DW_AT_APPLE_flags, Flags);
|
2012-11-19 22:42:10 +00:00
|
|
|
|
2016-05-24 21:19:28 +00:00
|
|
|
if (unsigned RVer = DIUnit->getRuntimeVersion())
|
|
|
|
NewCU.addUInt(Die, dwarf::DW_AT_APPLE_major_runtime_vers,
|
|
|
|
dwarf::DW_FORM_data1, RVer);
|
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2015-09-14 22:10:22 +00:00
|
|
|
if (DIUnit->getDWOId()) {
|
2015-09-22 23:21:00 +00:00
|
|
|
// This CU is either a clang module DWO or a skeleton CU.
|
2015-09-14 22:10:22 +00:00
|
|
|
NewCU.addUInt(Die, dwarf::DW_AT_GNU_dwo_id, dwarf::DW_FORM_data8,
|
|
|
|
DIUnit->getDWOId());
|
2019-11-29 11:26:00 +05:30
|
|
|
if (!DIUnit->getSplitDebugFilename().empty()) {
|
2015-09-22 23:21:00 +00:00
|
|
|
// This is a prefabricated skeleton CU.
|
2019-11-29 11:26:00 +05:30
|
|
|
dwarf::Attribute attrDWOName = getDwarfVersion() >= 5
|
|
|
|
? dwarf::DW_AT_dwo_name
|
|
|
|
: dwarf::DW_AT_GNU_dwo_name;
|
|
|
|
NewCU.addString(Die, attrDWOName, DIUnit->getSplitDebugFilename());
|
|
|
|
}
|
2015-09-14 22:10:22 +00:00
|
|
|
}
|
2018-12-14 22:44:46 +00:00
|
|
|
}
|
|
|
|
// Create new DwarfCompileUnit for the given metadata node with tag
|
|
|
|
// DW_TAG_compile_unit.
|
|
|
|
DwarfCompileUnit &
|
|
|
|
DwarfDebug::getOrCreateDwarfCompileUnit(const DICompileUnit *DIUnit) {
|
|
|
|
if (auto *CU = CUMap.lookup(DIUnit))
|
|
|
|
return *CU;
|
|
|
|
|
|
|
|
CompilationDir = DIUnit->getDirectory();
|
|
|
|
|
2019-08-15 15:54:37 +00:00
|
|
|
auto OwnedUnit = std::make_unique<DwarfCompileUnit>(
|
2018-12-14 22:44:46 +00:00
|
|
|
InfoHolder.getUnits().size(), DIUnit, Asm, this, &InfoHolder);
|
|
|
|
DwarfCompileUnit &NewCU = *OwnedUnit;
|
|
|
|
InfoHolder.addUnit(std::move(OwnedUnit));
|
|
|
|
|
2018-12-18 19:40:22 +00:00
|
|
|
for (auto *IE : DIUnit->getImportedEntities())
|
|
|
|
NewCU.addImportedEntity(IE);
|
|
|
|
|
2018-12-20 20:46:55 +00:00
|
|
|
// LTO with assembly output shares a single line table amongst multiple CUs.
|
|
|
|
// To avoid the compilation directory being ambiguous, let the line table
|
|
|
|
// explicitly describe the directory of all files, never relying on the
|
|
|
|
// compilation directory.
|
|
|
|
if (!Asm->OutStreamer->hasRawTextSupport() || SingleCU)
|
|
|
|
Asm->OutStreamer->emitDwarfFile0Directive(
|
|
|
|
CompilationDir, DIUnit->getFilename(),
|
|
|
|
NewCU.getMD5AsBytes(DIUnit->getFile()), DIUnit->getSource(),
|
|
|
|
NewCU.getUniqueID());
|
|
|
|
|
2018-12-14 22:44:46 +00:00
|
|
|
if (useSplitDwarf()) {
|
|
|
|
NewCU.setSkeleton(constructSkeletonCU(NewCU));
|
|
|
|
NewCU.setSection(Asm->getObjFileLowering().getDwarfInfoDWOSection());
|
|
|
|
} else {
|
|
|
|
finishUnitAttributes(DIUnit, NewCU);
|
|
|
|
NewCU.setSection(Asm->getObjFileLowering().getDwarfInfoSection());
|
|
|
|
}
|
2015-09-14 22:10:22 +00:00
|
|
|
|
2016-08-11 21:15:00 +00:00
|
|
|
CUMap.insert({DIUnit, &NewCU});
|
2018-12-14 22:44:46 +00:00
|
|
|
CUDieMap.insert({&NewCU.getUnitDie(), &NewCU});
|
2011-08-16 22:09:43 +00:00
|
|
|
return NewCU;
|
2009-05-20 23:19:06 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2014-08-31 05:41:15 +00:00
|
|
|
void DwarfDebug::constructAndAddImportedEntityDIE(DwarfCompileUnit &TheCU,
|
2015-04-29 16:38:44 +00:00
|
|
|
const DIImportedEntity *N) {
|
2017-07-27 00:06:53 +00:00
|
|
|
if (isa<DILocalScope>(N->getScope()))
|
|
|
|
return;
|
2015-04-21 18:44:06 +00:00
|
|
|
if (DIE *D = TheCU.getOrCreateContextDIE(N->getScope()))
|
|
|
|
D->addChild(TheCU.constructImportedEntityDIE(N));
|
2013-04-22 06:12:31 +00:00
|
|
|
}
|
|
|
|
|
2016-12-20 02:09:43 +00:00
|
|
|
/// Sort and unique GVEs by comparing their fragment offset.
|
|
|
|
static SmallVectorImpl<DwarfCompileUnit::GlobalExpr> &
|
|
|
|
sortGlobalExprs(SmallVectorImpl<DwarfCompileUnit::GlobalExpr> &GVEs) {
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 02:13:45 +00:00
|
|
|
llvm::sort(
|
|
|
|
GVEs, [](DwarfCompileUnit::GlobalExpr A, DwarfCompileUnit::GlobalExpr B) {
|
|
|
|
// Sort order: first null exprs, then exprs without fragment
|
|
|
|
// info, then sort by fragment offset in bits.
|
|
|
|
// FIXME: Come up with a more comprehensive comparator so
|
|
|
|
// the sorting isn't non-deterministic, and so the following
|
|
|
|
// std::unique call works correctly.
|
|
|
|
if (!A.Expr || !B.Expr)
|
|
|
|
return !!B.Expr;
|
|
|
|
auto FragmentA = A.Expr->getFragmentInfo();
|
|
|
|
auto FragmentB = B.Expr->getFragmentInfo();
|
|
|
|
if (!FragmentA || !FragmentB)
|
|
|
|
return !!FragmentB;
|
|
|
|
return FragmentA->OffsetInBits < FragmentB->OffsetInBits;
|
|
|
|
});
|
2016-12-20 02:09:43 +00:00
|
|
|
GVEs.erase(std::unique(GVEs.begin(), GVEs.end(),
|
|
|
|
[](DwarfCompileUnit::GlobalExpr A,
|
|
|
|
DwarfCompileUnit::GlobalExpr B) {
|
|
|
|
return A.Expr == B.Expr;
|
|
|
|
}),
|
|
|
|
GVEs.end());
|
|
|
|
return GVEs;
|
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Emit all Dwarf sections that should come prior to the content. Create
|
|
|
|
// global DIEs and emit initial debug info sections. This is invoked by
|
|
|
|
// the target AsmPrinter.
|
2012-11-19 22:42:15 +00:00
|
|
|
void DwarfDebug::beginModule() {
|
2016-11-18 19:43:18 +00:00
|
|
|
NamedRegionTimer T(DbgTimerName, DbgTimerDescription, DWARFGroupName,
|
|
|
|
DWARFGroupDescription, TimePassesIsEnabled);
|
2018-10-31 17:18:41 +00:00
|
|
|
if (DisableDebugInfoPrinting) {
|
|
|
|
MMI->setDebugInfoAvailability(false);
|
2010-04-27 19:46:33 +00:00
|
|
|
return;
|
2018-10-31 17:18:41 +00:00
|
|
|
}
|
2010-04-27 19:46:33 +00:00
|
|
|
|
2012-11-19 22:42:15 +00:00
|
|
|
const Module *M = MMI->getModule();
|
|
|
|
|
2016-06-01 02:58:40 +00:00
|
|
|
unsigned NumDebugCUs = std::distance(M->debug_compile_units_begin(),
|
|
|
|
M->debug_compile_units_end());
|
2016-04-08 22:43:03 +00:00
|
|
|
// Tell MMI whether we have debug info.
|
2018-10-31 17:18:41 +00:00
|
|
|
assert(MMI->hasDebugInfo() == (NumDebugCUs > 0) &&
|
|
|
|
"DebugInfoAvailabilty initialized unexpectedly");
|
2016-04-08 22:43:03 +00:00
|
|
|
SingleCU = NumDebugCUs == 1;
|
2016-12-20 02:09:43 +00:00
|
|
|
DenseMap<DIGlobalVariable *, SmallVector<DwarfCompileUnit::GlobalExpr, 1>>
|
|
|
|
GVMap;
|
2016-09-13 01:12:59 +00:00
|
|
|
for (const GlobalVariable &Global : M->globals()) {
|
2016-12-20 02:09:43 +00:00
|
|
|
SmallVector<DIGlobalVariableExpression *, 1> GVs;
|
2016-09-13 01:12:59 +00:00
|
|
|
Global.getDebugInfo(GVs);
|
2016-12-20 02:09:43 +00:00
|
|
|
for (auto *GVE : GVs)
|
|
|
|
GVMap[GVE->getVariable()].push_back({&Global, GVE->getExpression()});
|
2016-09-13 01:12:59 +00:00
|
|
|
}
|
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
// Create the symbol that designates the start of the unit's contribution
|
|
|
|
// to the string offsets table. In a split DWARF scenario, only the skeleton
|
|
|
|
// unit has the DW_AT_str_offsets_base attribute (and hence needs the symbol).
|
|
|
|
if (useSegmentedStringOffsetsTable())
|
|
|
|
(useSplitDwarf() ? SkeletonHolder : InfoHolder)
|
|
|
|
.setStringOffsetsStartSym(Asm->createTempSymbol("str_offsets_base"));
|
|
|
|
|
2018-10-26 11:25:12 +00:00
|
|
|
|
|
|
|
// Create the symbols that designates the start of the DWARF v5 range list
|
|
|
|
// and locations list tables. They are located past the table headers.
|
2018-10-20 07:36:39 +00:00
|
|
|
if (getDwarfVersion() >= 5) {
|
2018-10-26 11:25:12 +00:00
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
|
|
|
Holder.setRnglistsTableBaseSym(
|
|
|
|
Asm->createTempSymbol("rnglists_table_base"));
|
|
|
|
|
2018-10-20 07:36:39 +00:00
|
|
|
if (useSplitDwarf())
|
|
|
|
InfoHolder.setRnglistsTableBaseSym(
|
|
|
|
Asm->createTempSymbol("rnglists_dwo_table_base"));
|
|
|
|
}
|
2018-07-12 18:18:21 +00:00
|
|
|
|
2018-09-20 09:17:36 +00:00
|
|
|
// Create the symbol that points to the first entry following the debug
|
|
|
|
// address table (.debug_addr) header.
|
|
|
|
AddrPool.setLabel(Asm->createTempSymbol("addr_table_base"));
|
2019-12-05 12:45:13 -08:00
|
|
|
DebugLocs.setSym(Asm->createTempSymbol("loclists_table_base"));
|
2018-09-20 09:17:36 +00:00
|
|
|
|
2016-04-08 22:43:03 +00:00
|
|
|
for (DICompileUnit *CUNode : M->debug_compile_units()) {
|
2017-07-28 03:06:25 +00:00
|
|
|
// FIXME: Move local imported entities into a list attached to the
|
|
|
|
// subprogram, then this search won't be needed and a
|
|
|
|
// getImportedEntities().empty() test should go below with the rest.
|
|
|
|
bool HasNonLocalImportedEntities = llvm::any_of(
|
|
|
|
CUNode->getImportedEntities(), [](const DIImportedEntity *IE) {
|
|
|
|
return !isa<DILocalScope>(IE->getScope());
|
|
|
|
});
|
|
|
|
|
|
|
|
if (!HasNonLocalImportedEntities && CUNode->getEnumTypes().empty() &&
|
|
|
|
CUNode->getRetainedTypes().empty() &&
|
|
|
|
CUNode->getGlobalVariables().empty() && CUNode->getMacros().empty())
|
2017-05-26 18:52:56 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
DwarfCompileUnit &CU = getOrCreateDwarfCompileUnit(CUNode);
|
2016-12-20 02:09:43 +00:00
|
|
|
|
|
|
|
// Global Variables.
|
2017-08-19 01:15:06 +00:00
|
|
|
for (auto *GVE : CUNode->getGlobalVariables()) {
|
|
|
|
// Don't bother adding DIGlobalVariableExpressions listed in the CU if we
|
|
|
|
// already know about the variable and it isn't adding a constant
|
|
|
|
// expression.
|
|
|
|
auto &GVMapEntry = GVMap[GVE->getVariable()];
|
|
|
|
auto *Expr = GVE->getExpression();
|
|
|
|
if (!GVMapEntry.size() || (Expr && Expr->isConstant()))
|
|
|
|
GVMapEntry.push_back({nullptr, Expr});
|
|
|
|
}
|
2016-12-20 02:09:43 +00:00
|
|
|
DenseSet<DIGlobalVariable *> Processed;
|
|
|
|
for (auto *GVE : CUNode->getGlobalVariables()) {
|
|
|
|
DIGlobalVariable *GV = GVE->getVariable();
|
|
|
|
if (Processed.insert(GV).second)
|
|
|
|
CU.getOrCreateGlobalVariableDIE(GV, sortGlobalExprs(GVMap[GV]));
|
|
|
|
}
|
|
|
|
|
2015-04-20 18:52:06 +00:00
|
|
|
for (auto *Ty : CUNode->getEnumTypes()) {
|
2014-07-28 23:04:20 +00:00
|
|
|
// The enum types array by design contains pointers to
|
|
|
|
// MDNodes rather than DIRefs. Unique them here.
|
2016-04-23 21:08:00 +00:00
|
|
|
CU.getOrCreateTypeDIE(cast<DIType>(Ty));
|
2014-07-28 23:04:20 +00:00
|
|
|
}
|
2015-04-20 18:52:06 +00:00
|
|
|
for (auto *Ty : CUNode->getRetainedTypes()) {
|
2014-03-18 02:35:03 +00:00
|
|
|
// The retained types array by design contains pointers to
|
|
|
|
// MDNodes rather than DIRefs. Unique them here.
|
2016-04-30 01:44:07 +00:00
|
|
|
if (DIType *RT = dyn_cast<DIType>(Ty))
|
2016-04-15 15:57:41 +00:00
|
|
|
// There is no point in force-emitting a forward declaration.
|
|
|
|
CU.getOrCreateTypeDIE(RT);
|
2014-03-18 02:35:03 +00:00
|
|
|
}
|
2013-04-22 06:12:31 +00:00
|
|
|
// Emit imported_modules last so that the relevant context is already
|
|
|
|
// available.
|
2015-04-07 04:14:33 +00:00
|
|
|
for (auto *IE : CUNode->getImportedEntities())
|
2016-04-30 01:44:07 +00:00
|
|
|
constructAndAddImportedEntityDIE(CU, IE);
|
2013-03-11 23:39:23 +00:00
|
|
|
}
|
2009-05-20 23:21:38 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
void DwarfDebug::finishEntityDefinitions() {
|
|
|
|
for (const auto &Entity : ConcreteEntities) {
|
|
|
|
DIE *Die = Entity->getDIE();
|
|
|
|
assert(Die);
|
2014-06-13 22:18:23 +00:00
|
|
|
// FIXME: Consider the time-space tradeoff of just storing the unit pointer
|
2018-08-17 15:22:04 +00:00
|
|
|
// in the ConcreteEntities list, rather than looking it up again here.
|
2014-06-13 22:18:23 +00:00
|
|
|
// DIE::getUnit isn't simple - it walks parent pointers, etc.
|
2018-08-17 15:22:04 +00:00
|
|
|
DwarfCompileUnit *Unit = CUDieMap.lookup(Die->getUnitDie());
|
2014-06-13 22:18:23 +00:00
|
|
|
assert(Unit);
|
2018-08-17 15:22:04 +00:00
|
|
|
Unit->finishEntityDefinition(Entity.get());
|
2014-06-13 22:18:23 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
DebugInfo: Lazily attach definition attributes to definitions.
This is a precursor to fixing inlined debug info where the concrete,
out-of-line definition may preceed any inlined usage. To cope with this,
the attributes that may appear on the concrete definition or the
abstract definition are delayed until the end of the module. Then, if an
abstract definition was created, it is referenced (and no other
attributes are added to the out-of-line definition), otherwise the
attributes are added directly to the out-of-line definition.
In a couple of cases this causes not just reordering of attributes, but
reordering of types. When the creation of the attribute is delayed, if
that creation would create a type (such as for a DW_AT_type attribute)
then other top level DIEs may've been constructed during the delay,
causing the referenced type to be created and added after those
intervening DIEs. In the extreme case, in cross-cu-inlining.ll, this
actually causes the DW_TAG_basic_type for "int" to move from one CU to
another.
llvm-svn: 209674
2014-05-27 18:37:43 +00:00
|
|
|
void DwarfDebug::finishSubprogramDefinitions() {
|
2017-05-26 18:52:56 +00:00
|
|
|
for (const DISubprogram *SP : ProcessedSPNodes) {
|
|
|
|
assert(SP->getUnit()->getEmissionKind() != DICompileUnit::NoDebug);
|
|
|
|
forBothCUs(
|
|
|
|
getOrCreateDwarfCompileUnit(SP->getUnit()),
|
|
|
|
[&](DwarfCompileUnit &CU) { CU.finishSubprogramDefinition(SP); });
|
|
|
|
}
|
2012-11-22 00:59:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void DwarfDebug::finalizeModuleInfo() {
|
2015-03-10 16:58:10 +00:00
|
|
|
const TargetLoweringObjectFile &TLOF = Asm->getObjFileLowering();
|
|
|
|
|
2014-05-27 18:37:48 +00:00
|
|
|
finishSubprogramDefinitions();
|
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
finishEntityDefinitions();
|
2014-06-13 22:18:23 +00:00
|
|
|
|
2017-05-29 06:32:34 +00:00
|
|
|
// Include the DWO file name in the hash if there's more than one CU.
|
|
|
|
// This handles ThinLTO's situation where imported CUs may very easily be
|
|
|
|
// duplicate with the same CU partially imported into another ThinLTO unit.
|
|
|
|
StringRef DWOName;
|
|
|
|
if (CUMap.size() > 1)
|
|
|
|
DWOName = Asm->TM.Options.MCOptions.SplitDwarfFile;
|
|
|
|
|
2013-12-04 23:24:38 +00:00
|
|
|
// Handle anything that needs to be done on a per-unit basis after
|
|
|
|
// all other generation.
|
2014-11-01 01:11:19 +00:00
|
|
|
for (const auto &P : CUMap) {
|
|
|
|
auto &TheCU = *P.second;
|
2018-08-01 19:38:20 +00:00
|
|
|
if (TheCU.getCUNode()->isDebugDirectivesOnly())
|
|
|
|
continue;
|
2013-08-12 20:27:48 +00:00
|
|
|
// Emit DW_AT_containing_type attribute to connect types with their
|
|
|
|
// vtable holding type.
|
2014-11-01 01:11:19 +00:00
|
|
|
TheCU.constructContainingTypeDIEs();
|
2013-08-12 20:27:48 +00:00
|
|
|
|
2013-12-20 04:16:18 +00:00
|
|
|
// Add CU specific attributes if we need to add any.
|
2014-11-01 01:11:19 +00:00
|
|
|
// If we're splitting the dwarf out now that we've got the entire
|
|
|
|
// CU then add the dwo id to it.
|
|
|
|
auto *SkCU = TheCU.getSkeleton();
|
2019-12-05 19:51:30 -08:00
|
|
|
|
|
|
|
bool HasSplitUnit = SkCU && !TheCU.getUnitDie().children().empty();
|
|
|
|
|
|
|
|
if (HasSplitUnit) {
|
2019-11-29 11:26:00 +05:30
|
|
|
dwarf::Attribute attrDWOName = getDwarfVersion() >= 5
|
|
|
|
? dwarf::DW_AT_dwo_name
|
|
|
|
: dwarf::DW_AT_GNU_dwo_name;
|
2018-12-14 22:44:46 +00:00
|
|
|
finishUnitAttributes(TheCU.getCUNode(), TheCU);
|
2019-11-29 11:26:00 +05:30
|
|
|
TheCU.addString(TheCU.getUnitDie(), attrDWOName,
|
2018-12-14 22:44:46 +00:00
|
|
|
Asm->TM.Options.MCOptions.SplitDwarfFile);
|
2019-11-29 11:26:00 +05:30
|
|
|
SkCU->addString(SkCU->getUnitDie(), attrDWOName,
|
2018-12-14 22:44:46 +00:00
|
|
|
Asm->TM.Options.MCOptions.SplitDwarfFile);
|
2014-11-01 01:11:19 +00:00
|
|
|
// Emit a unique identifier for this CU.
|
2017-05-29 06:32:34 +00:00
|
|
|
uint64_t ID =
|
|
|
|
DIEHash(Asm).computeCUSignature(DWOName, TheCU.getUnitDie());
|
2018-05-22 17:27:31 +00:00
|
|
|
if (getDwarfVersion() >= 5) {
|
|
|
|
TheCU.setDWOId(ID);
|
|
|
|
SkCU->setDWOId(ID);
|
|
|
|
} else {
|
|
|
|
TheCU.addUInt(TheCU.getUnitDie(), dwarf::DW_AT_GNU_dwo_id,
|
|
|
|
dwarf::DW_FORM_data8, ID);
|
|
|
|
SkCU->addUInt(SkCU->getUnitDie(), dwarf::DW_AT_GNU_dwo_id,
|
|
|
|
dwarf::DW_FORM_data8, ID);
|
|
|
|
}
|
2018-09-20 09:17:36 +00:00
|
|
|
|
2018-10-20 07:36:39 +00:00
|
|
|
if (getDwarfVersion() < 5 && !SkeletonHolder.getRangeLists().empty()) {
|
2015-03-10 16:58:10 +00:00
|
|
|
const MCSymbol *Sym = TLOF.getDwarfRangesSection()->getBeginSymbol();
|
2014-11-01 01:11:19 +00:00
|
|
|
SkCU->addSectionLabel(SkCU->getUnitDie(), dwarf::DW_AT_GNU_ranges_base,
|
2015-03-10 16:58:10 +00:00
|
|
|
Sym, Sym);
|
|
|
|
}
|
2018-12-14 22:44:46 +00:00
|
|
|
} else if (SkCU) {
|
|
|
|
finishUnitAttributes(SkCU->getCUNode(), *SkCU);
|
2014-11-01 01:11:19 +00:00
|
|
|
}
|
2013-12-30 17:22:27 +00:00
|
|
|
|
2014-11-01 01:11:19 +00:00
|
|
|
// If we have code split among multiple sections or non-contiguous
|
|
|
|
// ranges of code then emit a DW_AT_ranges attribute on the unit that will
|
|
|
|
// remain in the .o file, otherwise add a DW_AT_low_pc.
|
|
|
|
// FIXME: We should use ranges allow reordering of code ala
|
|
|
|
// .subsections_via_symbols in mach-o. This would mean turning on
|
|
|
|
// ranges for all subprogram DIEs for mach-o.
|
2014-11-01 01:15:24 +00:00
|
|
|
DwarfCompileUnit &U = SkCU ? *SkCU : TheCU;
|
2018-10-20 06:02:15 +00:00
|
|
|
|
2014-11-03 23:10:59 +00:00
|
|
|
if (unsigned NumRanges = TheCU.getRanges().size()) {
|
2018-03-20 20:21:38 +00:00
|
|
|
if (NumRanges > 1 && useRangesSection())
|
2014-11-01 01:11:19 +00:00
|
|
|
// A DW_AT_low_pc attribute may also be specified in combination with
|
|
|
|
// DW_AT_ranges to specify the default base address for use in
|
|
|
|
// location lists (see Section 2.6.2) and range lists (see Section
|
|
|
|
// 2.17.3).
|
|
|
|
U.addUInt(U.getUnitDie(), dwarf::DW_AT_low_pc, dwarf::DW_FORM_addr, 0);
|
2014-11-03 23:10:59 +00:00
|
|
|
else
|
2019-10-02 22:27:24 +00:00
|
|
|
U.setBaseAddress(TheCU.getRanges().front().Begin);
|
2014-11-03 23:10:59 +00:00
|
|
|
U.attachRangesOrLowHighPC(U.getUnitDie(), TheCU.takeRanges());
|
2013-08-12 20:27:48 +00:00
|
|
|
}
|
2016-01-07 14:28:20 +00:00
|
|
|
|
2019-05-14 14:37:26 +00:00
|
|
|
// We don't keep track of which addresses are used in which CU so this
|
|
|
|
// is a bit pessimistic under LTO.
|
2020-05-17 12:17:31 -07:00
|
|
|
if ((HasSplitUnit || getDwarfVersion() >= 5) && !AddrPool.isEmpty())
|
2019-05-14 14:37:26 +00:00
|
|
|
U.addAddrTableBase();
|
|
|
|
|
2018-10-26 11:25:12 +00:00
|
|
|
if (getDwarfVersion() >= 5) {
|
|
|
|
if (U.hasRangeLists())
|
|
|
|
U.addRnglistsBase();
|
|
|
|
|
2019-11-23 20:04:36 +05:30
|
|
|
if (!DebugLocs.getLists().empty()) {
|
|
|
|
if (!useSplitDwarf())
|
|
|
|
U.addSectionLabel(U.getUnitDie(), dwarf::DW_AT_loclists_base,
|
|
|
|
DebugLocs.getSym(),
|
|
|
|
TLOF.getDwarfLoclistsSection()->getBeginSymbol());
|
2019-10-17 23:02:19 +00:00
|
|
|
}
|
2018-10-26 11:25:12 +00:00
|
|
|
}
|
2018-07-26 22:48:52 +00:00
|
|
|
|
2016-01-07 14:28:20 +00:00
|
|
|
auto *CUNode = cast<DICompileUnit>(P.first);
|
2020-04-03 12:44:09 +05:30
|
|
|
// If compile Unit has macros, emit "DW_AT_macro_info/DW_AT_macros"
|
|
|
|
// attribute.
|
2019-12-24 01:14:15 -08:00
|
|
|
if (CUNode->getMacros()) {
|
2020-04-03 12:44:09 +05:30
|
|
|
if (getDwarfVersion() >= 5) {
|
2020-05-30 11:11:09 +05:30
|
|
|
if (useSplitDwarf())
|
|
|
|
TheCU.addSectionDelta(
|
|
|
|
TheCU.getUnitDie(), dwarf::DW_AT_macros, U.getMacroLabelBegin(),
|
|
|
|
TLOF.getDwarfMacroDWOSection()->getBeginSymbol());
|
|
|
|
else
|
2020-04-03 12:44:09 +05:30
|
|
|
U.addSectionLabel(U.getUnitDie(), dwarf::DW_AT_macros,
|
2019-12-24 11:38:38 +05:30
|
|
|
U.getMacroLabelBegin(),
|
2020-04-03 12:44:09 +05:30
|
|
|
TLOF.getDwarfMacroSection()->getBeginSymbol());
|
|
|
|
} else {
|
|
|
|
if (useSplitDwarf())
|
|
|
|
TheCU.addSectionDelta(
|
|
|
|
TheCU.getUnitDie(), dwarf::DW_AT_macro_info,
|
|
|
|
U.getMacroLabelBegin(),
|
|
|
|
TLOF.getDwarfMacinfoDWOSection()->getBeginSymbol());
|
|
|
|
else
|
|
|
|
U.addSectionLabel(U.getUnitDie(), dwarf::DW_AT_macro_info,
|
|
|
|
U.getMacroLabelBegin(),
|
|
|
|
TLOF.getDwarfMacinfoSection()->getBeginSymbol());
|
|
|
|
}
|
|
|
|
}
|
2019-12-24 01:14:15 -08:00
|
|
|
}
|
2013-08-12 20:27:48 +00:00
|
|
|
|
2017-07-26 18:48:32 +00:00
|
|
|
// Emit all frontend-produced Skeleton CUs, i.e., Clang modules.
|
|
|
|
for (auto *CUNode : MMI->getModule()->debug_compile_units())
|
2017-07-27 15:24:20 +00:00
|
|
|
if (CUNode->getDWOId())
|
2017-07-26 18:48:32 +00:00
|
|
|
getOrCreateDwarfCompileUnit(CUNode);
|
|
|
|
|
2013-08-12 20:27:48 +00:00
|
|
|
// Compute DIE offsets and sizes.
|
2012-12-10 23:34:43 +00:00
|
|
|
InfoHolder.computeSizeAndOffsets();
|
|
|
|
if (useSplitDwarf())
|
|
|
|
SkeletonHolder.computeSizeAndOffsets();
|
2012-11-22 00:59:49 +00:00
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Emit all Dwarf sections that should come after the content.
|
2012-11-22 00:59:49 +00:00
|
|
|
void DwarfDebug::endModule() {
|
2014-04-28 04:05:08 +00:00
|
|
|
assert(CurFn == nullptr);
|
|
|
|
assert(CurMI == nullptr);
|
2012-11-22 00:59:49 +00:00
|
|
|
|
2019-03-19 13:16:28 +00:00
|
|
|
for (const auto &P : CUMap) {
|
|
|
|
auto &CU = *P.second;
|
|
|
|
CU.createBaseTypeDIEs();
|
|
|
|
}
|
|
|
|
|
2014-10-24 17:53:38 +00:00
|
|
|
// If we aren't actually generating debug info (check beginModule -
|
|
|
|
// conditionalized on !DisableDebugInfoPrinting and the presence of the
|
|
|
|
// llvm.dbg.cu metadata node)
|
2015-03-11 00:51:37 +00:00
|
|
|
if (!MMI->hasDebugInfo())
|
2013-11-19 09:04:36 +00:00
|
|
|
return;
|
2012-11-22 00:59:49 +00:00
|
|
|
|
|
|
|
// Finalize the debug info for the module.
|
|
|
|
finalizeModuleInfo();
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2015-03-10 16:58:10 +00:00
|
|
|
if (useSplitDwarf())
|
2019-12-03 19:40:46 +05:30
|
|
|
// Emit debug_loc.dwo/debug_loclists.dwo section.
|
2015-03-10 16:58:10 +00:00
|
|
|
emitDebugLocDWO();
|
|
|
|
else
|
2019-12-03 19:40:46 +05:30
|
|
|
// Emit debug_loc/debug_loclists section.
|
2015-03-10 16:58:10 +00:00
|
|
|
emitDebugLoc();
|
|
|
|
|
2013-11-19 09:04:50 +00:00
|
|
|
// Corresponding abbreviations into a abbrev section.
|
|
|
|
emitAbbreviations();
|
2012-11-27 22:43:42 +00:00
|
|
|
|
2015-03-11 00:51:37 +00:00
|
|
|
// Emit all the DIEs into a debug info section.
|
|
|
|
emitDebugInfo();
|
|
|
|
|
2013-11-19 09:04:50 +00:00
|
|
|
// Emit info into a debug aranges section.
|
2014-02-14 01:26:55 +00:00
|
|
|
if (GenerateARangeSection)
|
|
|
|
emitDebugARanges();
|
2012-11-27 22:43:42 +00:00
|
|
|
|
2013-11-19 09:04:50 +00:00
|
|
|
// Emit info into a debug ranges section.
|
|
|
|
emitDebugRanges();
|
2012-11-27 22:43:42 +00:00
|
|
|
|
2019-11-11 12:53:19 +05:30
|
|
|
if (useSplitDwarf())
|
|
|
|
// Emit info into a debug macinfo.dwo section.
|
|
|
|
emitDebugMacinfoDWO();
|
|
|
|
else
|
2020-04-03 12:44:09 +05:30
|
|
|
// Emit info into a debug macinfo/macro section.
|
2019-11-11 12:53:19 +05:30
|
|
|
emitDebugMacinfo();
|
2016-01-07 14:28:20 +00:00
|
|
|
|
2020-02-07 10:18:54 +05:30
|
|
|
emitDebugStr();
|
|
|
|
|
2013-11-19 09:04:50 +00:00
|
|
|
if (useSplitDwarf()) {
|
|
|
|
emitDebugStrDWO();
|
2012-11-30 23:59:06 +00:00
|
|
|
emitDebugInfoDWO();
|
2012-12-19 22:02:53 +00:00
|
|
|
emitDebugAbbrevDWO();
|
2014-03-18 01:17:26 +00:00
|
|
|
emitDebugLineDWO();
|
2018-10-20 08:12:36 +00:00
|
|
|
emitDebugRangesDWO();
|
2015-03-10 16:58:10 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2018-10-20 06:02:15 +00:00
|
|
|
emitDebugAddr();
|
|
|
|
|
2012-08-23 07:32:06 +00:00
|
|
|
// Emit info into the dwarf accelerator table sections.
|
2018-04-04 14:42:14 +00:00
|
|
|
switch (getAccelTableKind()) {
|
|
|
|
case AccelTableKind::Apple:
|
2011-11-07 09:24:32 +00:00
|
|
|
emitAccelNames();
|
|
|
|
emitAccelObjC();
|
|
|
|
emitAccelNamespaces();
|
|
|
|
emitAccelTypes();
|
2018-04-04 14:42:14 +00:00
|
|
|
break;
|
|
|
|
case AccelTableKind::Dwarf:
|
|
|
|
emitAccelDebugNames();
|
|
|
|
break;
|
|
|
|
case AccelTableKind::None:
|
|
|
|
break;
|
|
|
|
case AccelTableKind::Default:
|
|
|
|
llvm_unreachable("Default should have already been resolved.");
|
2011-11-07 09:24:32 +00:00
|
|
|
}
|
2012-11-19 22:42:10 +00:00
|
|
|
|
2013-08-30 00:40:17 +00:00
|
|
|
// Emit the pubnames and pubtypes sections if requested.
|
2017-09-12 21:50:41 +00:00
|
|
|
emitDebugPubSections();
|
2009-11-24 01:14:22 +00:00
|
|
|
|
2010-08-02 17:32:15 +00:00
|
|
|
// clean up.
|
2017-05-12 01:13:45 +00:00
|
|
|
// FIXME: AbstractVariables.clear();
|
2009-05-20 23:21:38 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
void DwarfDebug::ensureAbstractEntityIsCreated(DwarfCompileUnit &CU,
|
|
|
|
const DINode *Node,
|
|
|
|
const MDNode *ScopeNode) {
|
|
|
|
if (CU.getExistingAbstractEntity(Node))
|
2014-06-13 23:52:55 +00:00
|
|
|
return;
|
2014-06-04 23:50:52 +00:00
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
CU.createAbstractEntity(Node, LScopes.getOrCreateAbstractScope(
|
2015-04-29 16:38:44 +00:00
|
|
|
cast<DILocalScope>(ScopeNode)));
|
2014-06-04 23:50:52 +00:00
|
|
|
}
|
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
void DwarfDebug::ensureAbstractEntityIsCreatedIfScoped(DwarfCompileUnit &CU,
|
|
|
|
const DINode *Node, const MDNode *ScopeNode) {
|
|
|
|
if (CU.getExistingAbstractEntity(Node))
|
2014-06-13 23:52:55 +00:00
|
|
|
return;
|
2014-06-04 23:50:52 +00:00
|
|
|
|
2015-03-30 23:21:21 +00:00
|
|
|
if (LexicalScope *Scope =
|
2015-04-29 16:38:44 +00:00
|
|
|
LScopes.findAbstractScope(cast_or_null<DILocalScope>(ScopeNode)))
|
2018-08-17 15:22:04 +00:00
|
|
|
CU.createAbstractEntity(Node, Scope);
|
2014-06-04 23:50:52 +00:00
|
|
|
}
|
2017-08-17 21:26:39 +00:00
|
|
|
|
2016-11-30 23:48:50 +00:00
|
|
|
// Collect variable information from side table maintained by MF.
|
|
|
|
void DwarfDebug::collectVariableInfoFromMFTable(
|
2018-09-06 02:22:06 +00:00
|
|
|
DwarfCompileUnit &TheCU, DenseSet<InlinedEntity> &Processed) {
|
|
|
|
SmallDenseMap<InlinedEntity, DbgVariable *> MFVars;
|
2020-02-13 14:38:42 -08:00
|
|
|
LLVM_DEBUG(dbgs() << "DwarfDebug: collecting variables from MF side table\n");
|
2016-11-30 23:48:50 +00:00
|
|
|
for (const auto &VI : Asm->MF->getVariableDbgInfo()) {
|
2014-03-09 15:44:39 +00:00
|
|
|
if (!VI.Var)
|
2013-11-19 09:04:36 +00:00
|
|
|
continue;
|
2015-04-16 22:12:59 +00:00
|
|
|
assert(VI.Var->isValidLocationForIntrinsic(VI.Loc) &&
|
|
|
|
"Expected inlined-at fields to agree");
|
|
|
|
|
2018-09-06 02:22:06 +00:00
|
|
|
InlinedEntity Var(VI.Var, VI.Loc->getInlinedAt());
|
2015-04-15 22:29:27 +00:00
|
|
|
Processed.insert(Var);
|
2014-03-09 15:44:39 +00:00
|
|
|
LexicalScope *Scope = LScopes.findLexicalScope(VI.Loc);
|
2010-07-21 21:21:52 +00:00
|
|
|
|
2009-11-10 23:20:04 +00:00
|
|
|
// If variable scope is not found then skip this variable.
|
2020-02-13 14:38:42 -08:00
|
|
|
if (!Scope) {
|
|
|
|
LLVM_DEBUG(dbgs() << "Dropping debug info for " << VI.Var->getName()
|
|
|
|
<< ", no variable scope found\n");
|
2009-11-10 23:20:04 +00:00
|
|
|
continue;
|
2020-02-13 14:38:42 -08:00
|
|
|
}
|
2009-11-10 23:06:00 +00:00
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
ensureAbstractEntityIsCreatedIfScoped(TheCU, Var.first, Scope->getScopeNode());
|
2019-08-15 15:54:37 +00:00
|
|
|
auto RegVar = std::make_unique<DbgVariable>(
|
2018-09-06 02:22:06 +00:00
|
|
|
cast<DILocalVariable>(Var.first), Var.second);
|
AsmPrinter: Rewrite initialization of DbgVariable, NFC
There are three types of `DbgVariable`:
- alloca variables, created based on the MMI table,
- register variables, created based on DBG_VALUE instructions, and
- optimized-out variables.
This commit reconfigures `DbgVariable` to make it easier to tell which
kind we have, and make initialization a little clearer.
For MMI/alloca variables, `FrameIndex.size()` must always equal
`Expr.size()`, and there shouldn't be an `MInsn`. For register
variables (with a `MInsn`), `FrameIndex` must be empty, and `Expr`
should have 0 or 1 element depending on whether it has a complex
expression (registers with multiple locations use `DebugLocListIndex`).
Optimized-out variables shouldn't have any of these fields.
Moreover, this separates DBG_VALUE initialization until after the
variable is created, simplifying logic in a future commit that changes
`collectVariableInfo()` to stop creating empty .debug_loc entries/lists.
llvm-svn: 240243
2015-06-21 16:50:43 +00:00
|
|
|
RegVar->initializeMMI(VI.Expr, VI.Slot);
|
2020-02-13 14:38:42 -08:00
|
|
|
LLVM_DEBUG(dbgs() << "Created DbgVariable for " << VI.Var->getName()
|
|
|
|
<< "\n");
|
2017-07-25 23:32:59 +00:00
|
|
|
if (DbgVariable *DbgVar = MFVars.lookup(Var))
|
|
|
|
DbgVar->addMMIEntry(*RegVar);
|
|
|
|
else if (InfoHolder.addScopeVariable(Scope, RegVar.get())) {
|
|
|
|
MFVars.insert({Var, RegVar.get()});
|
2018-08-17 15:22:04 +00:00
|
|
|
ConcreteEntities.push_back(std::move(RegVar));
|
2017-07-25 23:32:59 +00:00
|
|
|
}
|
2009-10-06 01:26:37 +00:00
|
|
|
}
|
2010-05-20 19:57:06 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
/// Determine whether a *singular* DBG_VALUE is valid for the entirety of its
|
|
|
|
/// enclosing lexical scope. The check ensures there are no other instructions
|
|
|
|
/// in the same lexical scope preceding the DBG_VALUE and that its range is
|
|
|
|
/// either open or otherwise rolls off the end of the scope.
|
|
|
|
static bool validThroughout(LexicalScopes &LScopes,
|
|
|
|
const MachineInstr *DbgValue,
|
|
|
|
const MachineInstr *RangeEnd) {
|
|
|
|
assert(DbgValue->getDebugLoc() && "DBG_VALUE without a debug location");
|
|
|
|
auto MBB = DbgValue->getParent();
|
|
|
|
auto DL = DbgValue->getDebugLoc();
|
|
|
|
auto *LScope = LScopes.findLexicalScope(DL);
|
|
|
|
// Scope doesn't exist; this is a dead DBG_VALUE.
|
|
|
|
if (!LScope)
|
|
|
|
return false;
|
|
|
|
auto &LSRange = LScope->getRanges();
|
|
|
|
if (LSRange.size() == 0)
|
|
|
|
return false;
|
|
|
|
|
2020-04-08 12:24:13 +01:00
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
// Determine if the DBG_VALUE is valid at the beginning of its lexical block.
|
|
|
|
const MachineInstr *LScopeBegin = LSRange.front().first;
|
|
|
|
// Early exit if the lexical scope begins outside of the current block.
|
|
|
|
if (LScopeBegin->getParent() != MBB)
|
|
|
|
return false;
|
2020-04-08 12:24:13 +01:00
|
|
|
|
|
|
|
// If there are instructions belonging to our scope in another block, and
|
|
|
|
// we're not a constant (see DWARF2 comment below), then we can't be
|
|
|
|
// validThroughout.
|
|
|
|
const MachineInstr *LScopeEnd = LSRange.back().second;
|
|
|
|
if (RangeEnd && LScopeEnd->getParent() != MBB)
|
|
|
|
return false;
|
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
MachineBasicBlock::const_reverse_iterator Pred(DbgValue);
|
|
|
|
for (++Pred; Pred != MBB->rend(); ++Pred) {
|
|
|
|
if (Pred->getFlag(MachineInstr::FrameSetup))
|
|
|
|
break;
|
|
|
|
auto PredDL = Pred->getDebugLoc();
|
|
|
|
if (!PredDL || Pred->isMetaInstruction())
|
|
|
|
continue;
|
|
|
|
// Check whether the instruction preceding the DBG_VALUE is in the same
|
|
|
|
// (sub)scope as the DBG_VALUE.
|
|
|
|
if (DL->getScope() == PredDL->getScope())
|
|
|
|
return false;
|
|
|
|
auto *PredScope = LScopes.findLexicalScope(PredDL);
|
|
|
|
if (!PredScope || LScope->dominates(PredScope))
|
|
|
|
return false;
|
2011-07-08 17:09:57 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
// If the range of the DBG_VALUE is open-ended, report success.
|
|
|
|
if (!RangeEnd)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// Single, constant DBG_VALUEs in the prologue are promoted to be live
|
|
|
|
// throughout the function. This is a hack, presumably for DWARF v2 and not
|
|
|
|
// necessarily correct. It would be much better to use a dbg.declare instead
|
|
|
|
// if we know the constant is live throughout the scope.
|
|
|
|
if (DbgValue->getOperand(0).isImm() && MBB->pred_empty())
|
|
|
|
return true;
|
|
|
|
|
2020-05-18 09:25:29 +01:00
|
|
|
// Now check for situations where an "open-ended" DBG_VALUE isn't enough to
|
|
|
|
// determine eligibility for a single location, e.g. nested scopes, inlined
|
|
|
|
// functions.
|
|
|
|
// FIXME: For now we just handle a simple (but common) case where the scope
|
|
|
|
// is contained in MBB. We could be smarter here.
|
|
|
|
//
|
|
|
|
// At this point we know that our scope ends in MBB. So, if RangeEnd exists
|
|
|
|
// outside of the block we can ignore it; the location is just leaking outside
|
|
|
|
// its scope.
|
|
|
|
assert(LScopeEnd->getParent() == MBB && "Scope ends outside MBB");
|
|
|
|
if (RangeEnd->getParent() != DbgValue->getParent())
|
|
|
|
return true;
|
|
|
|
|
|
|
|
// The location range and variable's enclosing scope are both contained within
|
|
|
|
// MBB, test if location terminates before end of scope.
|
|
|
|
for (auto I = RangeEnd->getIterator(); I != MBB->end(); ++I)
|
|
|
|
if (&*I == LScopeEnd)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// There's a single location which starts at the scope start, and ends at or
|
|
|
|
// after the scope end.
|
|
|
|
return true;
|
2011-07-08 17:09:57 +00:00
|
|
|
}
|
|
|
|
|
2014-08-01 22:11:58 +00:00
|
|
|
/// Build the location list for all DBG_VALUEs in the function that
|
[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 11:28:20 +00:00
|
|
|
/// describe the same variable. The resulting DebugLocEntries will have
|
2014-08-01 22:11:58 +00:00
|
|
|
/// strict monotonically increasing begin addresses and will never
|
2019-06-10 08:41:06 +00:00
|
|
|
/// overlap. If the resulting list has only one entry that is valid
|
|
|
|
/// throughout variable's scope return true.
|
2014-08-01 22:11:58 +00:00
|
|
|
//
|
[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 11:28:20 +00:00
|
|
|
// See the definition of DbgValueHistoryMap::Entry for an explanation of the
|
|
|
|
// different kinds of history map entries. One thing to be aware of is that if
|
|
|
|
// a debug value is ended by another entry (rather than being valid until the
|
|
|
|
// end of the function), that entry's instruction may or may not be included in
|
|
|
|
// the range, depending on if the entry is a clobbering entry (it has an
|
|
|
|
// instruction that clobbers one or more preceding locations), or if it is an
|
|
|
|
// (overlapping) debug value entry. This distinction can be seen in the example
|
|
|
|
// below. The first debug value is ended by the clobbering entry 2, and the
|
|
|
|
// second and third debug values are ended by the overlapping debug value entry
|
|
|
|
// 4.
|
|
|
|
//
|
2014-08-01 22:11:58 +00:00
|
|
|
// Input:
|
|
|
|
//
|
[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 11:28:20 +00:00
|
|
|
// History map entries [type, end index, mi]
|
|
|
|
//
|
|
|
|
// 0 | [DbgValue, 2, DBG_VALUE $reg0, [...] (fragment 0, 32)]
|
|
|
|
// 1 | | [DbgValue, 4, DBG_VALUE $reg1, [...] (fragment 32, 32)]
|
|
|
|
// 2 | | [Clobber, $reg0 = [...], -, -]
|
|
|
|
// 3 | | [DbgValue, 4, DBG_VALUE 123, [...] (fragment 64, 32)]
|
|
|
|
// 4 [DbgValue, ~0, DBG_VALUE @g, [...] (fragment 0, 96)]
|
2014-08-01 22:11:58 +00:00
|
|
|
//
|
[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 11:28:20 +00:00
|
|
|
// Output [start, end) [Value...]:
|
2014-08-01 22:11:58 +00:00
|
|
|
//
|
[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 11:28:20 +00:00
|
|
|
// [0-1) [(reg0, fragment 0, 32)]
|
|
|
|
// [1-3) [(reg0, fragment 0, 32), (reg1, fragment 32, 32)]
|
|
|
|
// [3-4) [(reg1, fragment 32, 32), (123, fragment 64, 32)]
|
|
|
|
// [4-) [(@g, fragment 0, 96)]
|
2019-06-10 08:41:06 +00:00
|
|
|
bool DwarfDebug::buildLocationList(SmallVectorImpl<DebugLocEntry> &DebugLoc,
|
2019-04-10 09:07:43 +00:00
|
|
|
const DbgValueHistoryMap::Entries &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 11:28:20 +00:00
|
|
|
using OpenRange =
|
2019-06-13 10:23:26 +00:00
|
|
|
std::pair<DbgValueHistoryMap::EntryIndex, DbgValueLoc>;
|
[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 11:28:20 +00:00
|
|
|
SmallVector<OpenRange, 4> OpenRanges;
|
2019-06-10 08:41:06 +00:00
|
|
|
bool isSafeForSingleLocation = true;
|
|
|
|
const MachineInstr *StartDebugMI = nullptr;
|
|
|
|
const MachineInstr *EndMI = nullptr;
|
[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 11:28:20 +00:00
|
|
|
|
|
|
|
for (auto EB = Entries.begin(), EI = EB, EE = Entries.end(); EI != EE; ++EI) {
|
|
|
|
const MachineInstr *Instr = EI->getInstr();
|
|
|
|
|
|
|
|
// Remove all values that are no longer live.
|
|
|
|
size_t Index = std::distance(EB, EI);
|
|
|
|
auto Last =
|
|
|
|
remove_if(OpenRanges, [&](OpenRange &R) { return R.first <= Index; });
|
2014-08-01 22:11:58 +00:00
|
|
|
OpenRanges.erase(Last, OpenRanges.end());
|
|
|
|
|
[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 11:28:20 +00:00
|
|
|
// If we are dealing with a clobbering entry, this iteration will result in
|
|
|
|
// a location list entry starting after the clobbering instruction.
|
|
|
|
const MCSymbol *StartLabel =
|
|
|
|
EI->isClobber() ? getLabelAfterInsn(Instr) : getLabelBeforeInsn(Instr);
|
|
|
|
assert(StartLabel &&
|
|
|
|
"Forgot label before/after instruction starting a range!");
|
2014-08-01 22:11:58 +00:00
|
|
|
|
|
|
|
const MCSymbol *EndLabel;
|
2019-06-10 08:41:06 +00:00
|
|
|
if (std::next(EI) == Entries.end()) {
|
2015-03-05 02:05:42 +00:00
|
|
|
EndLabel = Asm->getFunctionEnd();
|
2019-06-10 08:41:06 +00:00
|
|
|
if (EI->isClobber())
|
|
|
|
EndMI = EI->getInstr();
|
|
|
|
}
|
[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 11:28:20 +00:00
|
|
|
else if (std::next(EI)->isClobber())
|
|
|
|
EndLabel = getLabelAfterInsn(std::next(EI)->getInstr());
|
2014-08-01 22:11:58 +00:00
|
|
|
else
|
[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 11:28:20 +00:00
|
|
|
EndLabel = getLabelBeforeInsn(std::next(EI)->getInstr());
|
2014-08-01 22:11:58 +00:00
|
|
|
assert(EndLabel && "Forgot label after instruction ending a range!");
|
|
|
|
|
[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 11:28:20 +00:00
|
|
|
if (EI->isDbgValue())
|
|
|
|
LLVM_DEBUG(dbgs() << "DotDebugLoc: " << *Instr << "\n");
|
2014-08-01 22:11:58 +00:00
|
|
|
|
[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 11:28:20 +00:00
|
|
|
// If this history map entry has a debug value, add that to the list of
|
2019-06-10 08:41:06 +00:00
|
|
|
// open ranges and check if its location is valid for a single value
|
|
|
|
// location.
|
[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 11:28:20 +00:00
|
|
|
if (EI->isDbgValue()) {
|
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 13:23:25 +00:00
|
|
|
// Do not add undef debug values, as they are redundant information in
|
|
|
|
// the location list entries. An undef debug results in an empty location
|
|
|
|
// description. If there are any non-undef fragments then padding pieces
|
|
|
|
// with empty location descriptions will automatically be inserted, and if
|
|
|
|
// all fragments are undef then the whole location list entry is
|
|
|
|
// redundant.
|
|
|
|
if (!Instr->isUndefDebugValue()) {
|
|
|
|
auto Value = getDebugLocValue(Instr);
|
|
|
|
OpenRanges.emplace_back(EI->getEndIndex(), Value);
|
2019-06-10 08:41:06 +00:00
|
|
|
|
|
|
|
// TODO: Add support for single value fragment locations.
|
|
|
|
if (Instr->getDebugExpression()->isFragment())
|
|
|
|
isSafeForSingleLocation = false;
|
|
|
|
|
|
|
|
if (!StartDebugMI)
|
|
|
|
StartDebugMI = Instr;
|
|
|
|
} else {
|
|
|
|
isSafeForSingleLocation = false;
|
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 13:23:25 +00:00
|
|
|
}
|
[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 11:28:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Location list entries with empty location descriptions are redundant
|
|
|
|
// information in DWARF, so do not emit those.
|
|
|
|
if (OpenRanges.empty())
|
|
|
|
continue;
|
[DebugInfo] Omit location list entries with empty ranges
Summary:
This fixes PR39710. In that case we emitted a location list looking like
this:
.Ldebug_loc0:
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_begin0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # DW_OP_reg5
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_end0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # super-register DW_OP_reg5
.quad 0
.quad 0
As seen, the first entry's beginning and ending addresses evalute to 0,
which meant that the entry inadvertently became an "end of list" entry,
resulting in the location list ending sooner than expected.
To fix this, omit all entries with empty ranges. Location list entries
with empty ranges do not have any effect, as specified by DWARF, so we
might as well drop them:
"A location list entry (but not a base address selection or end of list
entry) whose beginning and ending addresses are equal has no effect
because the size of the range covered by such an entry is zero."
Reviewers: davide, aprantl, dblaikie
Reviewed By: aprantl
Subscribers: javed.absar, JDevlieghere, llvm-commits
Tags: #debug-info
Differential Revision: https://reviews.llvm.org/D55919
llvm-svn: 350698
2019-01-09 09:58:59 +00:00
|
|
|
|
|
|
|
// Omit entries with empty ranges as they do not have any effect in DWARF.
|
|
|
|
if (StartLabel == EndLabel) {
|
|
|
|
LLVM_DEBUG(dbgs() << "Omitting location list entry with empty range.\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2019-06-13 10:23:26 +00:00
|
|
|
SmallVector<DbgValueLoc, 4> Values;
|
[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 11:28:20 +00:00
|
|
|
for (auto &R : OpenRanges)
|
|
|
|
Values.push_back(R.second);
|
|
|
|
DebugLoc.emplace_back(StartLabel, EndLabel, Values);
|
2014-08-11 20:59:28 +00:00
|
|
|
|
|
|
|
// Attempt to coalesce the ranges of two otherwise identical
|
|
|
|
// DebugLocEntries.
|
|
|
|
auto CurEntry = DebugLoc.rbegin();
|
2018-05-14 12:53:11 +00:00
|
|
|
LLVM_DEBUG({
|
Move the complex address expression out of DIVariable and into an extra
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.
Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.
By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.
The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)
This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.
What this patch doesn't do:
This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.
http://reviews.llvm.org/D4919
rdar://problem/17994491
Thanks to dblaikie and dexonsmith for reviewing this patch!
Note: I accidentally committed a bogus older version of this patch previously.
llvm-svn: 218787
2014-10-01 18:55:02 +00:00
|
|
|
dbgs() << CurEntry->getValues().size() << " Values:\n";
|
2015-05-26 20:06:51 +00:00
|
|
|
for (auto &Value : CurEntry->getValues())
|
2016-02-29 22:28:22 +00:00
|
|
|
Value.dump();
|
Move the complex address expression out of DIVariable and into an extra
argument of the llvm.dbg.declare/llvm.dbg.value intrinsics.
Previously, DIVariable was a variable-length field that has an optional
reference to a Metadata array consisting of a variable number of
complex address expressions. In the case of OpPiece expressions this is
wasting a lot of storage in IR, because when an aggregate type is, e.g.,
SROA'd into all of its n individual members, the IR will contain n copies
of the DIVariable, all alike, only differing in the complex address
reference at the end.
By making the complex address into an extra argument of the
dbg.value/dbg.declare intrinsics, all of the pieces can reference the
same variable and the complex address expressions can be uniqued across
the CU, too.
Down the road, this will allow us to move other flags, such as
"indirection" out of the DIVariable, too.
The new intrinsics look like this:
declare void @llvm.dbg.declare(metadata %storage, metadata %var, metadata %expr)
declare void @llvm.dbg.value(metadata %storage, i64 %offset, metadata %var, metadata %expr)
This patch adds a new LLVM-local tag to DIExpressions, so we can detect
and pretty-print DIExpression metadata nodes.
What this patch doesn't do:
This patch does not touch the "Indirect" field in DIVariable; but moving
that into the expression would be a natural next step.
http://reviews.llvm.org/D4919
rdar://problem/17994491
Thanks to dblaikie and dexonsmith for reviewing this patch!
Note: I accidentally committed a bogus older version of this patch previously.
llvm-svn: 218787
2014-10-01 18:55:02 +00:00
|
|
|
dbgs() << "-----\n";
|
|
|
|
});
|
2015-05-26 20:06:48 +00:00
|
|
|
|
|
|
|
auto PrevEntry = std::next(CurEntry);
|
|
|
|
if (PrevEntry != DebugLoc.rend() && PrevEntry->MergeRanges(*CurEntry))
|
|
|
|
DebugLoc.pop_back();
|
2014-08-01 22:11:58 +00:00
|
|
|
}
|
2019-06-10 08:41:06 +00:00
|
|
|
|
|
|
|
return DebugLoc.size() == 1 && isSafeForSingleLocation &&
|
|
|
|
validThroughout(LScopes, StartDebugMI, EndMI);
|
2014-08-01 22:11:58 +00:00
|
|
|
}
|
|
|
|
|
2018-08-17 15:22:04 +00:00
|
|
|
DbgEntity *DwarfDebug::createConcreteEntity(DwarfCompileUnit &TheCU,
|
|
|
|
LexicalScope &Scope,
|
|
|
|
const DINode *Node,
|
|
|
|
const DILocation *Location,
|
|
|
|
const MCSymbol *Sym) {
|
|
|
|
ensureAbstractEntityIsCreatedIfScoped(TheCU, Node, Scope.getScopeNode());
|
|
|
|
if (isa<const DILocalVariable>(Node)) {
|
|
|
|
ConcreteEntities.push_back(
|
2019-08-15 15:54:37 +00:00
|
|
|
std::make_unique<DbgVariable>(cast<const DILocalVariable>(Node),
|
2018-08-17 15:22:04 +00:00
|
|
|
Location));
|
|
|
|
InfoHolder.addScopeVariable(&Scope,
|
|
|
|
cast<DbgVariable>(ConcreteEntities.back().get()));
|
|
|
|
} else if (isa<const DILabel>(Node)) {
|
|
|
|
ConcreteEntities.push_back(
|
2019-08-15 15:54:37 +00:00
|
|
|
std::make_unique<DbgLabel>(cast<const DILabel>(Node),
|
2018-08-17 15:22:04 +00:00
|
|
|
Location, Sym));
|
|
|
|
InfoHolder.addScopeLabel(&Scope,
|
|
|
|
cast<DbgLabel>(ConcreteEntities.back().get()));
|
|
|
|
}
|
|
|
|
return ConcreteEntities.back().get();
|
AsmPrinter: Rewrite initialization of DbgVariable, NFC
There are three types of `DbgVariable`:
- alloca variables, created based on the MMI table,
- register variables, created based on DBG_VALUE instructions, and
- optimized-out variables.
This commit reconfigures `DbgVariable` to make it easier to tell which
kind we have, and make initialization a little clearer.
For MMI/alloca variables, `FrameIndex.size()` must always equal
`Expr.size()`, and there shouldn't be an `MInsn`. For register
variables (with a `MInsn`), `FrameIndex` must be empty, and `Expr`
should have 0 or 1 element depending on whether it has a complex
expression (registers with multiple locations use `DebugLocListIndex`).
Optimized-out variables shouldn't have any of these fields.
Moreover, this separates DBG_VALUE initialization until after the
variable is created, simplifying logic in a future commit that changes
`collectVariableInfo()` to stop creating empty .debug_loc entries/lists.
llvm-svn: 240243
2015-06-21 16:50:43 +00:00
|
|
|
}
|
2014-08-01 22:11:58 +00:00
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Find variables for each lexical scope.
|
2018-08-17 15:22:04 +00:00
|
|
|
void DwarfDebug::collectEntityInfo(DwarfCompileUnit &TheCU,
|
|
|
|
const DISubprogram *SP,
|
2018-09-06 02:22:06 +00:00
|
|
|
DenseSet<InlinedEntity> &Processed) {
|
2013-07-03 21:37:03 +00:00
|
|
|
// Grab the variable info that was squirreled away in the MMI side-table.
|
2017-05-12 01:13:45 +00:00
|
|
|
collectVariableInfoFromMFTable(TheCU, Processed);
|
2010-03-15 18:33:46 +00:00
|
|
|
|
2014-04-30 23:02:40 +00:00
|
|
|
for (const auto &I : DbgValues) {
|
2018-09-06 02:22:06 +00:00
|
|
|
InlinedEntity IV = I.first;
|
2015-04-15 22:29:27 +00:00
|
|
|
if (Processed.count(IV))
|
2010-05-20 19:57:06 +00:00
|
|
|
continue;
|
2010-03-15 18:33:46 +00:00
|
|
|
|
2015-04-15 22:29:27 +00:00
|
|
|
// Instruction ranges, specifying where IV is accessible.
|
2019-04-10 09:07:43 +00:00
|
|
|
const auto &HistoryMapEntries = I.second;
|
|
|
|
if (HistoryMapEntries.empty())
|
2011-03-26 02:19:36 +00:00
|
|
|
continue;
|
2010-05-25 23:40:22 +00:00
|
|
|
|
2014-04-24 06:44:33 +00:00
|
|
|
LexicalScope *Scope = nullptr;
|
2018-09-06 02:22:06 +00:00
|
|
|
const DILocalVariable *LocalVar = cast<DILocalVariable>(IV.first);
|
2015-04-29 16:38:44 +00:00
|
|
|
if (const DILocation *IA = IV.second)
|
2018-09-06 02:22:06 +00:00
|
|
|
Scope = LScopes.findInlinedScope(LocalVar->getScope(), IA);
|
2015-02-17 00:02:27 +00:00
|
|
|
else
|
2018-09-06 02:22:06 +00:00
|
|
|
Scope = LScopes.findLexicalScope(LocalVar->getScope());
|
2010-05-20 19:57:06 +00:00
|
|
|
// If variable scope is not found then skip this variable.
|
2010-05-21 00:10:20 +00:00
|
|
|
if (!Scope)
|
2010-05-20 19:57:06 +00:00
|
|
|
continue;
|
|
|
|
|
2015-04-15 22:29:27 +00:00
|
|
|
Processed.insert(IV);
|
2018-08-17 15:22:04 +00:00
|
|
|
DbgVariable *RegVar = cast<DbgVariable>(createConcreteEntity(TheCU,
|
2018-09-06 02:22:06 +00:00
|
|
|
*Scope, LocalVar, IV.second));
|
AsmPrinter: Rewrite initialization of DbgVariable, NFC
There are three types of `DbgVariable`:
- alloca variables, created based on the MMI table,
- register variables, created based on DBG_VALUE instructions, and
- optimized-out variables.
This commit reconfigures `DbgVariable` to make it easier to tell which
kind we have, and make initialization a little clearer.
For MMI/alloca variables, `FrameIndex.size()` must always equal
`Expr.size()`, and there shouldn't be an `MInsn`. For register
variables (with a `MInsn`), `FrameIndex` must be empty, and `Expr`
should have 0 or 1 element depending on whether it has a complex
expression (registers with multiple locations use `DebugLocListIndex`).
Optimized-out variables shouldn't have any of these fields.
Moreover, this separates DBG_VALUE initialization until after the
variable is created, simplifying logic in a future commit that changes
`collectVariableInfo()` to stop creating empty .debug_loc entries/lists.
llvm-svn: 240243
2015-06-21 16:50:43 +00:00
|
|
|
|
[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 11:28:20 +00:00
|
|
|
const MachineInstr *MInsn = HistoryMapEntries.front().getInstr();
|
2011-03-26 02:19:36 +00:00
|
|
|
assert(MInsn->isDebugValue() && "History must begin with debug value");
|
|
|
|
|
2017-06-16 22:40:04 +00:00
|
|
|
// Check if there is a single DBG_VALUE, valid throughout the var's scope.
|
[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 11:28:20 +00:00
|
|
|
// If the history map contains a single debug value, there may be an
|
|
|
|
// additional entry which clobbers the debug value.
|
2019-06-10 08:41:06 +00:00
|
|
|
size_t HistSize = HistoryMapEntries.size();
|
[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 11:28:20 +00:00
|
|
|
bool SingleValueWithClobber =
|
2019-06-10 08:41:06 +00:00
|
|
|
HistSize == 2 && HistoryMapEntries[1].isClobber();
|
|
|
|
if (HistSize == 1 || SingleValueWithClobber) {
|
[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 11:28:20 +00:00
|
|
|
const auto *End =
|
|
|
|
SingleValueWithClobber ? HistoryMapEntries[1].getInstr() : nullptr;
|
|
|
|
if (validThroughout(LScopes, MInsn, End)) {
|
|
|
|
RegVar->initializeDbgValue(MInsn);
|
|
|
|
continue;
|
|
|
|
}
|
2015-06-21 16:54:56 +00:00
|
|
|
}
|
[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 11:28:20 +00:00
|
|
|
|
2018-06-29 14:23:28 +00:00
|
|
|
// Do not emit location lists if .debug_loc secton is disabled.
|
|
|
|
if (!useLocSection())
|
|
|
|
continue;
|
2010-05-25 23:40:22 +00:00
|
|
|
|
2013-01-28 17:33:26 +00:00
|
|
|
// Handle multiple DBG_VALUE instructions describing one variable.
|
2015-06-21 16:54:56 +00:00
|
|
|
DebugLocStream::ListBuilder List(DebugLocs, TheCU, *Asm, *RegVar, *MInsn);
|
2014-08-01 22:11:58 +00:00
|
|
|
|
|
|
|
// Build the location list for this variable.
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
SmallVector<DebugLocEntry, 8> Entries;
|
2019-06-10 08:41:06 +00:00
|
|
|
bool isValidSingleLocation = buildLocationList(Entries, HistoryMapEntries);
|
|
|
|
|
|
|
|
// Check whether buildLocationList managed to merge all locations to one
|
|
|
|
// that is valid throughout the variable's scope. If so, produce single
|
|
|
|
// value location.
|
|
|
|
if (isValidSingleLocation) {
|
|
|
|
RegVar->initializeDbgValue(Entries[0].getValues()[0]);
|
|
|
|
continue;
|
|
|
|
}
|
2015-04-17 16:28:58 +00:00
|
|
|
|
2016-02-29 17:06:46 +00:00
|
|
|
// If the variable has a DIBasicType, extract it. Basic types cannot have
|
2015-04-17 16:28:58 +00:00
|
|
|
// unique identifiers, so don't bother resolving the type with the
|
|
|
|
// identifier map.
|
2015-04-29 16:38:44 +00:00
|
|
|
const DIBasicType *BT = dyn_cast<DIBasicType>(
|
2018-09-06 02:22:06 +00:00
|
|
|
static_cast<const Metadata *>(LocalVar->getType()));
|
2015-04-17 16:28:58 +00:00
|
|
|
|
2015-03-02 22:02:33 +00:00
|
|
|
// Finalize the entry by lowering it into a DWARF bytestream.
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
for (auto &Entry : Entries)
|
2019-03-19 13:16:28 +00:00
|
|
|
Entry.finalize(*Asm, List, BT, TheCU);
|
2010-03-15 18:33:46 +00:00
|
|
|
}
|
2010-05-14 21:01:35 +00:00
|
|
|
|
2018-09-06 02:22:06 +00:00
|
|
|
// For each InlinedEntity collected from DBG_LABEL instructions, convert to
|
2018-08-17 15:22:04 +00:00
|
|
|
// DWARF-related DbgLabel.
|
|
|
|
for (const auto &I : DbgLabels) {
|
2018-09-06 02:22:06 +00:00
|
|
|
InlinedEntity IL = I.first;
|
2018-08-17 15:22:04 +00:00
|
|
|
const MachineInstr *MI = I.second;
|
|
|
|
if (MI == nullptr)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LexicalScope *Scope = nullptr;
|
2018-09-06 02:22:06 +00:00
|
|
|
const DILabel *Label = cast<DILabel>(IL.first);
|
2019-08-14 17:58:45 +00:00
|
|
|
// The scope could have an extra lexical block file.
|
|
|
|
const DILocalScope *LocalScope =
|
|
|
|
Label->getScope()->getNonLexicalBlockFileScope();
|
2018-08-17 15:22:04 +00:00
|
|
|
// Get inlined DILocation if it is inlined label.
|
|
|
|
if (const DILocation *IA = IL.second)
|
2019-08-14 17:58:45 +00:00
|
|
|
Scope = LScopes.findInlinedScope(LocalScope, IA);
|
2018-08-17 15:22:04 +00:00
|
|
|
else
|
2019-08-14 17:58:45 +00:00
|
|
|
Scope = LScopes.findLexicalScope(LocalScope);
|
2018-08-17 15:22:04 +00:00
|
|
|
// If label scope is not found then skip this label.
|
|
|
|
if (!Scope)
|
|
|
|
continue;
|
|
|
|
|
2018-09-06 02:22:06 +00:00
|
|
|
Processed.insert(IL);
|
2018-08-17 15:22:04 +00:00
|
|
|
/// At this point, the temporary label is created.
|
|
|
|
/// Save the temporary label to DbgLabel entity to get the
|
|
|
|
/// actually address when generating Dwarf DIE.
|
|
|
|
MCSymbol *Sym = getLabelBeforeInsn(MI);
|
2018-09-06 02:22:06 +00:00
|
|
|
createConcreteEntity(TheCU, *Scope, Label, IL.second, Sym);
|
2018-08-17 15:22:04 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Collect info for variables/labels that were optimized out.
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
for (const DINode *DN : SP->getRetainedNodes()) {
|
2018-09-06 02:22:06 +00:00
|
|
|
if (!Processed.insert(InlinedEntity(DN, nullptr)).second)
|
|
|
|
continue;
|
2018-08-17 15:22:04 +00:00
|
|
|
LexicalScope *Scope = nullptr;
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
if (auto *DV = dyn_cast<DILocalVariable>(DN)) {
|
2018-08-17 15:22:04 +00:00
|
|
|
Scope = LScopes.findLexicalScope(DV->getScope());
|
|
|
|
} else if (auto *DL = dyn_cast<DILabel>(DN)) {
|
|
|
|
Scope = LScopes.findLexicalScope(DL->getScope());
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
}
|
2018-08-17 15:22:04 +00:00
|
|
|
|
|
|
|
if (Scope)
|
|
|
|
createConcreteEntity(TheCU, *Scope, DN, nullptr);
|
2010-05-14 21:01:35 +00:00
|
|
|
}
|
2010-05-25 23:40:22 +00:00
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Process beginning of an instruction.
|
2010-10-26 17:49:02 +00:00
|
|
|
void DwarfDebug::beginInstruction(const MachineInstr *MI) {
|
2020-03-17 17:56:28 -07:00
|
|
|
const MachineFunction &MF = *MI->getMF();
|
|
|
|
const auto *SP = MF.getFunction().getSubprogram();
|
|
|
|
bool NoDebug =
|
|
|
|
!SP || SP->getUnit()->getEmissionKind() == DICompileUnit::NoDebug;
|
|
|
|
|
|
|
|
// When describing calls, we need a label for the call instruction.
|
|
|
|
// TODO: Add support for targets with delay slots.
|
|
|
|
if (!NoDebug && SP->areAllCallsDescribed() &&
|
|
|
|
MI->isCandidateForCallSiteEntry(MachineInstr::AnyInBundle) &&
|
|
|
|
!MI->hasDelaySlot()) {
|
|
|
|
const TargetInstrInfo *TII = MF.getSubtarget().getInstrInfo();
|
|
|
|
bool IsTail = TII->isTailCall(*MI);
|
|
|
|
// For tail calls, we need the address of the branch instruction for
|
|
|
|
// DW_AT_call_pc.
|
|
|
|
if (IsTail)
|
|
|
|
requestLabelBeforeInsn(MI);
|
|
|
|
// For non-tail calls, we need the return address for the call for
|
|
|
|
// DW_AT_call_return_pc. Under GDB tuning, this information is needed for
|
|
|
|
// tail calls as well.
|
|
|
|
requestLabelAfterInsn(MI);
|
|
|
|
}
|
|
|
|
|
2016-02-10 20:55:49 +00:00
|
|
|
DebugHandlerBase::beginInstruction(MI);
|
|
|
|
assert(CurMI);
|
|
|
|
|
2020-03-17 17:56:28 -07:00
|
|
|
if (NoDebug)
|
2017-05-26 17:05:15 +00:00
|
|
|
return;
|
|
|
|
|
2016-12-09 19:15:32 +00:00
|
|
|
// Check if source location changes, but ignore DBG_VALUE and CFI locations.
|
2018-02-14 17:35:52 +00:00
|
|
|
// If the instruction is part of the function frame setup code, do not emit
|
|
|
|
// any line record, as there is no correspondence with any user code.
|
|
|
|
if (MI->isMetaInstruction() || MI->getFlag(MachineInstr::FrameSetup))
|
2016-11-22 19:46:51 +00:00
|
|
|
return;
|
|
|
|
const DebugLoc &DL = MI->getDebugLoc();
|
2016-12-12 20:49:11 +00:00
|
|
|
// When we emit a line-0 record, we don't update PrevInstLoc; so look at
|
|
|
|
// the last line number actually emitted, to see if it was line 0.
|
|
|
|
unsigned LastAsmLine =
|
|
|
|
Asm->OutStreamer->getContext().getCurrentDwarfLoc().getLine();
|
|
|
|
|
|
|
|
if (DL == PrevInstLoc) {
|
|
|
|
// If we have an ongoing unspecified location, nothing to do here.
|
|
|
|
if (!DL)
|
|
|
|
return;
|
|
|
|
// We have an explicit location, same as the previous location.
|
|
|
|
// But we might be coming back to it after a line 0 record.
|
|
|
|
if (LastAsmLine == 0 && DL.getLine() != 0) {
|
|
|
|
// Reinstate the source location but not marked as a statement.
|
|
|
|
const MDNode *Scope = DL.getScope();
|
|
|
|
recordSourceLine(DL.getLine(), DL.getCol(), Scope, /*Flags=*/0);
|
|
|
|
}
|
2016-11-22 19:46:51 +00:00
|
|
|
return;
|
2016-12-12 20:49:11 +00:00
|
|
|
}
|
2016-11-22 19:46:51 +00:00
|
|
|
|
|
|
|
if (!DL) {
|
|
|
|
// We have an unspecified location, which might want to be line 0.
|
2016-12-12 20:49:11 +00:00
|
|
|
// If we have already emitted a line-0 record, don't repeat it.
|
|
|
|
if (LastAsmLine == 0)
|
|
|
|
return;
|
|
|
|
// If user said Don't Do That, don't do that.
|
|
|
|
if (UnknownLocations == Disable)
|
|
|
|
return;
|
2018-10-11 23:37:58 +00:00
|
|
|
// See if we have a reason to emit a line-0 record now.
|
|
|
|
// Reasons to emit a line-0 record include:
|
|
|
|
// - User asked for it (UnknownLocations).
|
|
|
|
// - Instruction has a label, so it's referenced from somewhere else,
|
|
|
|
// possibly debug information; we want it to have a source location.
|
|
|
|
// - Instruction is at the top of a block; we don't want to inherit the
|
|
|
|
// location from the physically previous (maybe unrelated) block.
|
|
|
|
if (UnknownLocations == Enable || PrevLabel ||
|
|
|
|
(PrevInstBB && PrevInstBB != MI->getParent())) {
|
|
|
|
// Preserve the file and column numbers, if we can, to save space in
|
|
|
|
// the encoded line table.
|
|
|
|
// Do not update PrevInstLoc, it remembers the last non-0 line.
|
|
|
|
const MDNode *Scope = nullptr;
|
|
|
|
unsigned Column = 0;
|
|
|
|
if (PrevInstLoc) {
|
|
|
|
Scope = PrevInstLoc.getScope();
|
|
|
|
Column = PrevInstLoc.getCol();
|
|
|
|
}
|
|
|
|
recordSourceLine(/*Line=*/0, Column, Scope, /*Flags=*/0);
|
2011-03-25 17:20:59 +00:00
|
|
|
}
|
2016-11-22 19:46:51 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-10-11 23:37:58 +00:00
|
|
|
// We have an explicit location, different from the previous location.
|
|
|
|
// Don't repeat a line-0 record, but otherwise emit the new location.
|
|
|
|
// (The new location might be an explicit line 0, which we do emit.)
|
2019-01-16 23:26:29 +00:00
|
|
|
if (DL.getLine() == 0 && LastAsmLine == 0)
|
2018-10-11 23:37:58 +00:00
|
|
|
return;
|
|
|
|
unsigned Flags = 0;
|
|
|
|
if (DL == PrologEndLoc) {
|
|
|
|
Flags |= DWARF2_FLAG_PROLOGUE_END | DWARF2_FLAG_IS_STMT;
|
|
|
|
PrologEndLoc = DebugLoc();
|
|
|
|
}
|
|
|
|
// If the line changed, we call that a new statement; unless we went to
|
|
|
|
// line 0 and came back, in which case it is not a new statement.
|
|
|
|
unsigned OldLine = PrevInstLoc ? PrevInstLoc.getLine() : LastAsmLine;
|
|
|
|
if (DL.getLine() && DL.getLine() != OldLine)
|
|
|
|
Flags |= DWARF2_FLAG_IS_STMT;
|
|
|
|
|
|
|
|
const MDNode *Scope = DL.getScope();
|
|
|
|
recordSourceLine(DL.getLine(), DL.getCol(), Scope, Flags);
|
|
|
|
|
|
|
|
// If we're not at line 0, remember this location.
|
|
|
|
if (DL.getLine())
|
|
|
|
PrevInstLoc = DL;
|
2009-10-01 20:31:14 +00:00
|
|
|
}
|
|
|
|
|
2014-05-27 22:47:41 +00:00
|
|
|
static DebugLoc findPrologueEndLoc(const MachineFunction *MF) {
|
|
|
|
// First known non-DBG_VALUE and non-frame setup location marks
|
|
|
|
// the beginning of the function body.
|
|
|
|
for (const auto &MBB : *MF)
|
|
|
|
for (const auto &MI : MBB)
|
2017-05-22 20:47:09 +00:00
|
|
|
if (!MI.isMetaInstruction() && !MI.getFlag(MachineInstr::FrameSetup) &&
|
2015-10-08 07:48:49 +00:00
|
|
|
MI.getDebugLoc())
|
2014-05-27 22:47:41 +00:00
|
|
|
return MI.getDebugLoc();
|
|
|
|
return DebugLoc();
|
|
|
|
}
|
|
|
|
|
2019-01-22 17:24:16 +00:00
|
|
|
/// Register a source line with debug info. Returns the unique label that was
|
|
|
|
/// emitted and which provides correspondence to the source line list.
|
|
|
|
static void recordSourceLine(AsmPrinter &Asm, unsigned Line, unsigned Col,
|
|
|
|
const MDNode *S, unsigned Flags, unsigned CUID,
|
|
|
|
uint16_t DwarfVersion,
|
|
|
|
ArrayRef<std::unique_ptr<DwarfCompileUnit>> DCUs) {
|
|
|
|
StringRef Fn;
|
|
|
|
unsigned FileNo = 1;
|
|
|
|
unsigned Discriminator = 0;
|
|
|
|
if (auto *Scope = cast_or_null<DIScope>(S)) {
|
|
|
|
Fn = Scope->getFilename();
|
|
|
|
if (Line != 0 && DwarfVersion >= 4)
|
|
|
|
if (auto *LBF = dyn_cast<DILexicalBlockFile>(Scope))
|
|
|
|
Discriminator = LBF->getDiscriminator();
|
|
|
|
|
|
|
|
FileNo = static_cast<DwarfCompileUnit &>(*DCUs[CUID])
|
|
|
|
.getOrCreateSourceID(Scope->getFile());
|
|
|
|
}
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm.OutStreamer->emitDwarfLocDirective(FileNo, Line, Col, Flags, 0,
|
2019-01-22 17:24:16 +00:00
|
|
|
Discriminator, Fn);
|
|
|
|
}
|
|
|
|
|
|
|
|
DebugLoc DwarfDebug::emitInitialLocDirective(const MachineFunction &MF,
|
|
|
|
unsigned CUID) {
|
|
|
|
// Get beginning of function.
|
|
|
|
if (DebugLoc PrologEndLoc = findPrologueEndLoc(&MF)) {
|
|
|
|
// Ensure the compile unit is created if the function is called before
|
|
|
|
// beginFunction().
|
|
|
|
(void)getOrCreateDwarfCompileUnit(
|
|
|
|
MF.getFunction().getSubprogram()->getUnit());
|
|
|
|
// We'd like to list the prologue as "not statements" but GDB behaves
|
|
|
|
// poorly if we do that. Revisit this with caution/GDB (7.5+) testing.
|
|
|
|
const DISubprogram *SP = PrologEndLoc->getInlinedAtScope()->getSubprogram();
|
|
|
|
::recordSourceLine(*Asm, SP->getScopeLine(), 0, SP, DWARF2_FLAG_IS_STMT,
|
|
|
|
CUID, getDwarfVersion(), getUnits());
|
|
|
|
return PrologEndLoc;
|
|
|
|
}
|
|
|
|
return DebugLoc();
|
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Gather pre-function debug information. Assumes being called immediately
|
|
|
|
// after the function entry point has been emitted.
|
2017-02-16 18:48:33 +00:00
|
|
|
void DwarfDebug::beginFunctionImpl(const MachineFunction *MF) {
|
2013-12-03 15:10:23 +00:00
|
|
|
CurFn = MF;
|
2013-11-01 23:14:17 +00:00
|
|
|
|
2017-12-15 22:22:58 +00:00
|
|
|
auto *SP = MF->getFunction().getSubprogram();
|
2017-05-25 23:11:28 +00:00
|
|
|
assert(LScopes.empty() || SP == LScopes.getCurrentFunctionScope()->getScopeNode());
|
2017-05-26 18:52:56 +00:00
|
|
|
if (SP->getUnit()->getEmissionKind() == DICompileUnit::NoDebug)
|
2016-04-08 22:43:03 +00:00
|
|
|
return;
|
2017-05-26 18:52:56 +00:00
|
|
|
|
|
|
|
DwarfCompileUnit &CU = getOrCreateDwarfCompileUnit(SP->getUnit());
|
2017-05-25 23:11:28 +00:00
|
|
|
|
|
|
|
// Set DwarfDwarfCompileUnitID in MCContext to the Compile Unit this function
|
|
|
|
// belongs to so that we add to the correct per-cu line table in the
|
|
|
|
// non-asm case.
|
2015-04-24 19:11:51 +00:00
|
|
|
if (Asm->OutStreamer->hasRawTextSupport())
|
2014-02-05 18:00:21 +00:00
|
|
|
// Use a single line table if we are generating assembly.
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->getContext().setDwarfCompileUnitID(0);
|
2013-05-21 00:57:22 +00:00
|
|
|
else
|
2017-05-26 18:52:56 +00:00
|
|
|
Asm->OutStreamer->getContext().setDwarfCompileUnitID(CU.getUniqueID());
|
2013-02-05 21:52:47 +00:00
|
|
|
|
2011-05-11 19:22:19 +00:00
|
|
|
// Record beginning of function.
|
2019-01-22 17:24:16 +00:00
|
|
|
PrologEndLoc = emitInitialLocDirective(
|
|
|
|
*MF, Asm->OutStreamer->getContext().getDwarfCompileUnitID());
|
2009-05-15 09:23:25 +00:00
|
|
|
}
|
|
|
|
|
2017-02-16 18:48:33 +00:00
|
|
|
void DwarfDebug::skippedNonDebugFunction() {
|
|
|
|
// If we don't have a subprogram for this function then there will be a hole
|
|
|
|
// in the range information. Keep note of this by setting the previously used
|
|
|
|
// section to nullptr.
|
|
|
|
PrevCU = nullptr;
|
|
|
|
CurFn = nullptr;
|
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Gather and emit post-function debug information.
|
2017-02-16 18:48:33 +00:00
|
|
|
void DwarfDebug::endFunctionImpl(const MachineFunction *MF) {
|
2017-12-15 22:22:58 +00:00
|
|
|
const DISubprogram *SP = MF->getFunction().getSubprogram();
|
2017-02-16 18:48:33 +00:00
|
|
|
|
2014-10-14 17:12:02 +00:00
|
|
|
assert(CurFn == MF &&
|
|
|
|
"endFunction should be called with the same function as beginFunction");
|
2013-12-03 15:10:23 +00:00
|
|
|
|
2013-12-09 23:57:44 +00:00
|
|
|
// Set DwarfDwarfCompileUnitID in MCContext to default value.
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->getContext().setDwarfCompileUnitID(0);
|
2012-11-19 22:42:10 +00:00
|
|
|
|
2011-08-15 22:04:40 +00:00
|
|
|
LexicalScope *FnScope = LScopes.getCurrentFunctionScope();
|
2016-12-15 23:17:52 +00:00
|
|
|
assert(!FnScope || SP == FnScope->getScopeNode());
|
2016-04-15 15:57:41 +00:00
|
|
|
DwarfCompileUnit &TheCU = *CUMap.lookup(SP->getUnit());
|
2018-08-01 19:38:20 +00:00
|
|
|
if (TheCU.getCUNode()->isDebugDirectivesOnly()) {
|
|
|
|
PrevLabel = nullptr;
|
|
|
|
CurFn = nullptr;
|
|
|
|
return;
|
|
|
|
}
|
2014-10-23 00:06:27 +00:00
|
|
|
|
2018-09-06 02:22:06 +00:00
|
|
|
DenseSet<InlinedEntity> Processed;
|
|
|
|
collectEntityInfo(TheCU, SP, Processed);
|
2011-08-15 22:04:40 +00:00
|
|
|
|
2014-09-19 17:03:16 +00:00
|
|
|
// Add the range of this function to the list of ranges for the CU.
|
2019-10-02 22:27:24 +00:00
|
|
|
TheCU.addRange({Asm->getFunctionBegin(), Asm->getFunctionEnd()});
|
2014-09-19 17:03:16 +00:00
|
|
|
|
|
|
|
// Under -gmlt, skip building the subprogram if there are no inlined
|
2017-01-19 00:44:11 +00:00
|
|
|
// subroutines inside it. But with -fdebug-info-for-profiling, the subprogram
|
|
|
|
// is still needed as we need its source location.
|
Change debug-info-for-profiling from a TargetOption to a function attribute.
Summary: LTO requires the debug-info-for-profiling to be a function attribute.
Reviewers: echristo, mehdi_amini, dblaikie, probinson, aprantl
Reviewed By: mehdi_amini, dblaikie, aprantl
Subscribers: aprantl, probinson, ahatanak, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D29203
llvm-svn: 293833
2017-02-01 22:45:09 +00:00
|
|
|
if (!TheCU.getCUNode()->getDebugInfoForProfiling() &&
|
2017-01-19 00:44:11 +00:00
|
|
|
TheCU.getCUNode()->getEmissionKind() == DICompileUnit::LineTablesOnly &&
|
Disable the -gmlt optimization implemented in r218129 under Darwin due to issues with dsymutil.
r218129 omits DW_TAG_subprograms which have no inlined subroutines when
emitting -gmlt data. This makes -gmlt very low cost for -O0 builds.
Darwin's dsymutil reasonably considers a CU empty if it has no
subprograms (which occurs with the above optimization in -O0 programs
without any force_inline function calls) and drops the line table, CU,
and everything in this situation, making backtraces impossible.
Until dsymutil is modified to account for this, disable this
optimization on Darwin to preserve the desired functionality.
(see r218545, which should be reverted after this patch, for other
discussion/details)
Footnote:
In the long term, it doesn't look like this scheme (of simplified debug
info to describe inlining to enable backtracing) is tenable, it is far
too size inefficient for optimized code (the DW_TAG_inlined_subprograms,
even once compressed, are nearly twice as large as the line table
itself (also compressed)) and we'll be considering things like Cary's
two level line table proposal to encode all this information directly in
the line table.
llvm-svn: 218702
2014-09-30 21:28:32 +00:00
|
|
|
LScopes.getAbstractScopesList().empty() && !IsDarwin) {
|
2014-10-24 17:57:34 +00:00
|
|
|
assert(InfoHolder.getScopeVariables().empty());
|
2014-09-19 17:03:16 +00:00
|
|
|
PrevLabel = nullptr;
|
|
|
|
CurFn = nullptr;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-10-13 20:44:58 +00:00
|
|
|
#ifndef NDEBUG
|
|
|
|
size_t NumAbstractScopes = LScopes.getAbstractScopesList().size();
|
|
|
|
#endif
|
2011-08-10 20:55:27 +00:00
|
|
|
// Construct abstract scopes.
|
2014-03-07 19:09:39 +00:00
|
|
|
for (LexicalScope *AScope : LScopes.getAbstractScopesList()) {
|
2015-04-29 16:38:44 +00:00
|
|
|
auto *SP = cast<DISubprogram>(AScope->getScopeNode());
|
[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.
In order to set breakpoints on labels and list source code around
labels, we need collect debug information for labels, i.e., label
name, the function label belong, line number in the file, and the
address label located. In order to keep these information in LLVM
IR and to allow backend to generate debug information correctly.
We create a new kind of metadata for labels, DILabel. The format
of DILabel is
!DILabel(scope: !1, name: "foo", file: !2, line: 3)
We hope to keep debug information as much as possible even the
code is optimized. So, we create a new kind of intrinsic for label
metadata to avoid the metadata is eliminated with basic block.
The intrinsic will keep existing if we keep it from optimized out.
The format of the intrinsic is
llvm.dbg.label(metadata !1)
It has only one argument, that is the DILabel metadata. The
intrinsic will follow the label immediately. Backend could get the
label metadata through the intrinsic's parameter.
We also create DIBuilder API for labels to be used by Frontend.
Frontend could use createLabel() to allocate DILabel objects, and use
insertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.
Differential Revision: https://reviews.llvm.org/D45024
Patch by Hsiangkai Wang.
llvm-svn: 331841
2018-05-09 02:40:45 +00:00
|
|
|
for (const DINode *DN : SP->getRetainedNodes()) {
|
2018-09-06 02:22:06 +00:00
|
|
|
if (!Processed.insert(InlinedEntity(DN, nullptr)).second)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
const MDNode *Scope = nullptr;
|
|
|
|
if (auto *DV = dyn_cast<DILocalVariable>(DN))
|
|
|
|
Scope = DV->getScope();
|
|
|
|
else if (auto *DL = dyn_cast<DILabel>(DN))
|
|
|
|
Scope = DL->getScope();
|
|
|
|
else
|
|
|
|
llvm_unreachable("Unexpected DI type!");
|
|
|
|
|
|
|
|
// Collect info for variables/labels that were optimized out.
|
|
|
|
ensureAbstractEntityIsCreated(TheCU, DN, Scope);
|
|
|
|
assert(LScopes.getAbstractScopesList().size() == NumAbstractScopes
|
|
|
|
&& "ensureAbstractEntityIsCreated inserted abstract scopes");
|
2010-06-25 22:07:34 +00:00
|
|
|
}
|
2017-05-12 01:13:45 +00:00
|
|
|
constructAbstractSubprogramScopeDIE(TheCU, AScope);
|
2011-08-10 20:55:27 +00:00
|
|
|
}
|
2012-11-19 22:42:10 +00:00
|
|
|
|
2016-12-15 23:37:38 +00:00
|
|
|
ProcessedSPNodes.insert(SP);
|
2018-10-05 20:37:17 +00:00
|
|
|
DIE &ScopeDIE = TheCU.constructSubprogramScopeDIE(SP, FnScope);
|
Provide gmlt-like inline scope information in the skeleton CU to facilitate symbolication without needing the .dwo files
Clang -gsplit-dwarf self-host -O0, binary increases by 0.0005%, -O2,
binary increases by 25%.
A large binary inside Google, split-dwarf, -O0, and other internal flags
(GDB index, etc) increases by 1.8%, optimized build is 35%.
The size impact may be somewhat greater in .o files (I haven't measured
that much - since the linked executable -O0 numbers seemed low enough)
due to relocations. These relocations could be removed if we taught the
llvm-symbolizer to handle indexed addressing in the .o file (GDB can't
cope with this just yet, but GDB won't be reading this info anyway).
Also debug_ranges could be shared between .o and .dwo, though ideally
debug_ranges would get a schema that could used index(+offset)
addressing, and move to the .dwo file, then we'd be back to sharing
addresses in the address pool again.
But for now, these sizes seem small enough to go ahead with this.
Verified that no other DW_TAGs are produced into the .o file other than
subprograms and inlined_subroutines.
llvm-svn: 221306
2014-11-04 22:12:25 +00:00
|
|
|
if (auto *SkelCU = TheCU.getSkeleton())
|
2016-08-24 18:29:49 +00:00
|
|
|
if (!LScopes.getAbstractScopesList().empty() &&
|
|
|
|
TheCU.getCUNode()->getSplitDebugInlining())
|
2016-12-15 23:17:52 +00:00
|
|
|
SkelCU->constructSubprogramScopeDIE(SP, FnScope);
|
2011-08-15 22:04:40 +00:00
|
|
|
|
2018-10-05 20:37:17 +00:00
|
|
|
// Construct call site entries.
|
|
|
|
constructCallSiteEntryDIEs(*SP, TheCU, ScopeDIE, *MF);
|
|
|
|
|
2009-05-20 23:21:38 +00:00
|
|
|
// Clear debug info
|
2014-05-21 22:41:17 +00:00
|
|
|
// Ownership of DbgVariables is a bit subtle - ScopeVariables owns all the
|
|
|
|
// DbgVariables except those that are also in AbstractVariables (since they
|
|
|
|
// can be used cross-function)
|
2014-10-24 17:57:34 +00:00
|
|
|
InfoHolder.getScopeVariables().clear();
|
2018-08-17 15:22:04 +00:00
|
|
|
InfoHolder.getScopeLabels().clear();
|
2014-04-24 06:44:33 +00:00
|
|
|
PrevLabel = nullptr;
|
|
|
|
CurFn = nullptr;
|
2009-05-20 23:19:06 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Register a source line with debug info. Returns the unique label that was
|
|
|
|
// emitted and which provides correspondence to the source line list.
|
2011-05-11 19:22:19 +00:00
|
|
|
void DwarfDebug::recordSourceLine(unsigned Line, unsigned Col, const MDNode *S,
|
|
|
|
unsigned Flags) {
|
2019-01-22 17:24:16 +00:00
|
|
|
::recordSourceLine(*Asm, Line, Col, S, Flags,
|
|
|
|
Asm->OutStreamer->getContext().getDwarfCompileUnitID(),
|
|
|
|
getDwarfVersion(), getUnits());
|
2009-05-15 09:23:25 +00:00
|
|
|
}
|
|
|
|
|
2009-05-20 23:22:40 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Emit Methods
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2012-11-30 23:59:06 +00:00
|
|
|
// Emit the debug info section.
|
|
|
|
void DwarfDebug::emitDebugInfo() {
|
2013-12-05 18:06:10 +00:00
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
2015-03-10 16:58:10 +00:00
|
|
|
Holder.emitUnits(/* UseOffsets */ false);
|
2012-11-30 23:59:06 +00:00
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Emit the abbreviation section.
|
2012-11-20 23:30:11 +00:00
|
|
|
void DwarfDebug::emitAbbreviations() {
|
2013-12-05 18:06:10 +00:00
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
2013-12-05 07:43:55 +00:00
|
|
|
|
|
|
|
Holder.emitAbbrevs(Asm->getObjFileLowering().getDwarfAbbrevSection());
|
2012-12-19 22:02:53 +00:00
|
|
|
}
|
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
void DwarfDebug::emitStringOffsetsTableHeader() {
|
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
2018-07-26 14:36:07 +00:00
|
|
|
Holder.getStringPool().emitStringOffsetsTableHeader(
|
|
|
|
*Asm, Asm->getObjFileLowering().getDwarfStrOffSection(),
|
|
|
|
Holder.getStringOffsetsStartSym());
|
2018-01-26 18:52:58 +00:00
|
|
|
}
|
|
|
|
|
2018-01-29 14:52:34 +00:00
|
|
|
template <typename AccelTableT>
|
|
|
|
void DwarfDebug::emitAccel(AccelTableT &Accel, MCSection *Section,
|
2015-03-10 22:00:25 +00:00
|
|
|
StringRef TableName) {
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->SwitchSection(Section);
|
2011-11-07 09:24:32 +00:00
|
|
|
|
|
|
|
// Emit the full data.
|
[CodeGen] Refactor AppleAccelTable
Summary:
This commit separates the abstract accelerator table data structure
from the code for writing out an on-disk representation of a specific
accelerator table format. The idea is that former (now called
AccelTable<T>) can be reused for the DWARF v5 accelerator tables
as-is, without any further customizations.
Some bits of the emission code (now living in the EmissionContext class)
can be reused for DWARF v5 as well, but the subtle differences in the
layout of various subtables mean the sharing is not always possible.
(Also, the individual emit*** functions are fairly simple so there's a
tradeoff between making a bigger general-purpose function, and two
smaller targeted functions.)
Another advantage of this setup is that more of the serialization logic
can be hidden in the .cpp file -- I have moved declarations of the
header and all the emission functions there.
Reviewers: JDevlieghere, aprantl, probinson, dblaikie
Subscribers: echristo, clayborg, vleschuk, llvm-commits
Differential Revision: https://reviews.llvm.org/D43285
llvm-svn: 325516
2018-02-19 16:12:20 +00:00
|
|
|
emitAppleAccelTable(Asm, Accel, TableName, Section->getBeginSymbol());
|
2014-09-11 21:12:48 +00:00
|
|
|
}
|
|
|
|
|
2018-04-04 14:42:14 +00:00
|
|
|
void DwarfDebug::emitAccelDebugNames() {
|
2018-04-09 14:38:53 +00:00
|
|
|
// Don't emit anything if we have no compilation units to index.
|
|
|
|
if (getUnits().empty())
|
|
|
|
return;
|
|
|
|
|
2018-04-04 14:42:14 +00:00
|
|
|
emitDWARF5AccelTable(Asm, AccelDebugNames, *this, getUnits());
|
|
|
|
}
|
|
|
|
|
2014-09-11 21:12:48 +00:00
|
|
|
// Emit visible names into a hashed accelerator table section.
|
|
|
|
void DwarfDebug::emitAccelNames() {
|
|
|
|
emitAccel(AccelNames, Asm->getObjFileLowering().getDwarfAccelNamesSection(),
|
2015-03-10 22:00:25 +00:00
|
|
|
"Names");
|
2011-11-07 09:24:32 +00:00
|
|
|
}
|
|
|
|
|
2012-12-20 21:58:40 +00:00
|
|
|
// Emit objective C classes and categories into a hashed accelerator table
|
|
|
|
// section.
|
2011-11-07 09:24:32 +00:00
|
|
|
void DwarfDebug::emitAccelObjC() {
|
2014-09-11 21:12:48 +00:00
|
|
|
emitAccel(AccelObjC, Asm->getObjFileLowering().getDwarfAccelObjCSection(),
|
2015-03-10 22:00:25 +00:00
|
|
|
"ObjC");
|
2011-11-07 09:24:32 +00:00
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Emit namespace dies into a hashed accelerator table.
|
2011-11-07 09:24:32 +00:00
|
|
|
void DwarfDebug::emitAccelNamespaces() {
|
2014-09-11 21:12:48 +00:00
|
|
|
emitAccel(AccelNamespace,
|
|
|
|
Asm->getObjFileLowering().getDwarfAccelNamespaceSection(),
|
2015-03-10 22:00:25 +00:00
|
|
|
"namespac");
|
2011-11-07 09:24:32 +00:00
|
|
|
}
|
|
|
|
|
2012-11-27 22:43:45 +00:00
|
|
|
// Emit type dies into a hashed accelerator table.
|
2011-11-07 09:24:32 +00:00
|
|
|
void DwarfDebug::emitAccelTypes() {
|
2014-09-11 21:12:48 +00:00
|
|
|
emitAccel(AccelTypes, Asm->getObjFileLowering().getDwarfAccelTypesSection(),
|
2015-03-10 22:00:25 +00:00
|
|
|
"types");
|
2011-11-07 09:24:32 +00:00
|
|
|
}
|
|
|
|
|
2013-09-13 00:35:05 +00:00
|
|
|
// Public name handling.
|
|
|
|
// The format for the various pubnames:
|
|
|
|
//
|
|
|
|
// dwarf pubnames - offset/name pairs where the offset is the offset into the CU
|
|
|
|
// for the DIE that is named.
|
|
|
|
//
|
|
|
|
// gnu pubnames - offset/index value/name tuples where the offset is the offset
|
|
|
|
// into the CU and the index value is computed according to the type of value
|
|
|
|
// for the DIE that is named.
|
|
|
|
//
|
|
|
|
// For type units the offset is the offset of the skeleton DIE. For split dwarf
|
|
|
|
// it's the offset within the debug_info/debug_types dwo section, however, the
|
|
|
|
// reference in the pubname header doesn't change.
|
|
|
|
|
|
|
|
/// computeIndexValue - Compute the gdb index value for the DIE and CU.
|
2013-12-09 23:32:48 +00:00
|
|
|
static dwarf::PubIndexEntryDescriptor computeIndexValue(DwarfUnit *CU,
|
2013-11-21 00:48:22 +00:00
|
|
|
const DIE *Die) {
|
2017-02-03 00:44:18 +00:00
|
|
|
// Entities that ended up only in a Type Unit reference the CU instead (since
|
|
|
|
// the pub entry has offsets within the CU there's no real offset that can be
|
|
|
|
// provided anyway). As it happens all such entities (namespaces and types,
|
|
|
|
// types only in C++ at that) are rendered as TYPE+EXTERNAL. If this turns out
|
|
|
|
// not to be true it would be necessary to persist this information from the
|
|
|
|
// point at which the entry is added to the index data structure - since by
|
|
|
|
// the time the index is built from that, the original type/namespace DIE in a
|
|
|
|
// type unit has already been destroyed so it can't be queried for properties
|
|
|
|
// like tag, etc.
|
|
|
|
if (Die->getTag() == dwarf::DW_TAG_compile_unit)
|
|
|
|
return dwarf::PubIndexEntryDescriptor(dwarf::GIEK_TYPE,
|
|
|
|
dwarf::GIEL_EXTERNAL);
|
2013-10-16 01:37:49 +00:00
|
|
|
dwarf::GDBIndexEntryLinkage Linkage = dwarf::GIEL_STATIC;
|
|
|
|
|
|
|
|
// We could have a specification DIE that has our most of our knowledge,
|
|
|
|
// look for that now.
|
Reapply "AsmPrinter: Change DIEValue to be stored by value"
This reverts commit r238350, effectively reapplying r238349 after fixing
(all?) the problems, all somehow related to how I was using
`AlignedArrayCharUnion<>` inside `DIEValue`:
- MSVC can only handle `sizeof()` on types, not values. Change the
assert.
- GCC doesn't know the `is_trivially_copyable` type trait. Instead of
asserting it, add destructors.
- Call placement new even when constructing POD (i.e., the pointers).
- Instead of copying the char buffer, copy the casted classes.
I've left in a couple of `static_assert`s that I think both MSVC and GCC
know how to handle. If the bots disagree with me, I'll remove them.
- Check that the constructed type is either standard layout or a
pointer. This protects against a programming error: we really want
the "small" `DIEValue`s to be small and simple, so don't
accidentally change them not to be.
- Similarly, check that the size of the buffer is no bigger than a
`uint64_t` or a pointer. (I thought checking against
`sizeof(uint64_t)` would be good enough, but Chandler suggested that
pointers might sometimes be bigger than that in the context of
sanitizers.)
I've also committed r238359 in the meantime, which introduces a
DIEValue.def to simplify dispatching between the various types (thanks
to a review comment by David Blaikie). Without that, this commit would
be almost unintelligible.
Here's the original commit message:
--
Change `DIEValue` to be stored/passed/etc. by value, instead of
reference. It's now a discriminated union, with a `Val` field storing
the actual type. The classes that used to inherit from `DIEValue` no
longer do. There are two categories of these:
- Small values fit in a single pointer and are stored by value.
- Large values require auxiliary storage, and are stored by reference.
The only non-mechanical change is to tools/dsymutil/DwarfLinker.cpp. It
was relying on `DIEInteger`s being passed around by reference, so I
replaced that assumption with a `PatchLocation` type that stores a safe
reference to where the `DIEInteger` lives instead.
This commit causes a temporary regression in memory usage, since I've
left merging `DIEAbbrevData` into `DIEValue` for a follow-up commit. I
measured an increase from 845 MB to 879 MB, around 3.9%. The follow-up
drops it lower than the starting point, and I've only recently brought
the memory this low anyway, so I'm committing these changes separately
to keep them incremental. (I also considered swapping the commits, but
the other one first would cause a lot more code churn.)
(I'm looking at `llc` memory usage on `verify-uselistorder.lto.opt.bc`;
see r236629 for details.)
--
llvm-svn: 238362
2015-05-27 22:14:58 +00:00
|
|
|
if (DIEValue SpecVal = Die->findAttribute(dwarf::DW_AT_specification)) {
|
|
|
|
DIE &SpecDIE = SpecVal.getDIEEntry().getEntry();
|
2014-04-25 19:33:43 +00:00
|
|
|
if (SpecDIE.findAttribute(dwarf::DW_AT_external))
|
2013-10-16 01:37:49 +00:00
|
|
|
Linkage = dwarf::GIEL_EXTERNAL;
|
|
|
|
} else if (Die->findAttribute(dwarf::DW_AT_external))
|
|
|
|
Linkage = dwarf::GIEL_EXTERNAL;
|
2013-09-13 00:35:05 +00:00
|
|
|
|
|
|
|
switch (Die->getTag()) {
|
|
|
|
case dwarf::DW_TAG_class_type:
|
|
|
|
case dwarf::DW_TAG_structure_type:
|
|
|
|
case dwarf::DW_TAG_union_type:
|
|
|
|
case dwarf::DW_TAG_enumeration_type:
|
2013-09-23 20:55:35 +00:00
|
|
|
return dwarf::PubIndexEntryDescriptor(
|
2019-10-02 01:39:48 +00:00
|
|
|
dwarf::GIEK_TYPE,
|
|
|
|
dwarf::isCPlusPlus((dwarf::SourceLanguage)CU->getLanguage())
|
|
|
|
? dwarf::GIEL_EXTERNAL
|
|
|
|
: dwarf::GIEL_STATIC);
|
2013-09-13 00:35:05 +00:00
|
|
|
case dwarf::DW_TAG_typedef:
|
|
|
|
case dwarf::DW_TAG_base_type:
|
|
|
|
case dwarf::DW_TAG_subrange_type:
|
2013-09-19 20:40:26 +00:00
|
|
|
return dwarf::PubIndexEntryDescriptor(dwarf::GIEK_TYPE, dwarf::GIEL_STATIC);
|
2013-09-13 00:35:05 +00:00
|
|
|
case dwarf::DW_TAG_namespace:
|
2013-09-19 20:40:26 +00:00
|
|
|
return dwarf::GIEK_TYPE;
|
2013-09-13 00:35:05 +00:00
|
|
|
case dwarf::DW_TAG_subprogram:
|
2013-09-23 22:59:14 +00:00
|
|
|
return dwarf::PubIndexEntryDescriptor(dwarf::GIEK_FUNCTION, Linkage);
|
2013-09-13 00:35:05 +00:00
|
|
|
case dwarf::DW_TAG_variable:
|
2013-09-23 22:59:14 +00:00
|
|
|
return dwarf::PubIndexEntryDescriptor(dwarf::GIEK_VARIABLE, Linkage);
|
2013-09-13 00:35:05 +00:00
|
|
|
case dwarf::DW_TAG_enumerator:
|
2013-09-19 20:40:26 +00:00
|
|
|
return dwarf::PubIndexEntryDescriptor(dwarf::GIEK_VARIABLE,
|
|
|
|
dwarf::GIEL_STATIC);
|
2013-09-13 00:35:05 +00:00
|
|
|
default:
|
2013-09-19 20:40:26 +00:00
|
|
|
return dwarf::GIEK_NONE;
|
2013-09-13 00:35:05 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
/// emitDebugPubSections - Emit visible names and types into debug pubnames and
|
|
|
|
/// pubtypes sections.
|
|
|
|
void DwarfDebug::emitDebugPubSections() {
|
2014-03-06 01:42:00 +00:00
|
|
|
for (const auto &NU : CUMap) {
|
|
|
|
DwarfCompileUnit *TheU = NU.second;
|
2017-09-12 21:50:41 +00:00
|
|
|
if (!TheU->hasDwarfPubSections())
|
2014-03-11 23:35:06 +00:00
|
|
|
continue;
|
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
bool GnuStyle = TheU->getCUNode()->getNameTableKind() ==
|
|
|
|
DICompileUnit::DebugNameTableKind::GNU;
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->SwitchSection(
|
|
|
|
GnuStyle ? Asm->getObjFileLowering().getDwarfGnuPubNamesSection()
|
|
|
|
: Asm->getObjFileLowering().getDwarfPubNamesSection());
|
|
|
|
emitDebugPubSection(GnuStyle, "Names", TheU, TheU->getGlobalNames());
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->SwitchSection(
|
|
|
|
GnuStyle ? Asm->getObjFileLowering().getDwarfGnuPubTypesSection()
|
|
|
|
: Asm->getObjFileLowering().getDwarfPubTypesSection());
|
|
|
|
emitDebugPubSection(GnuStyle, "Types", TheU, TheU->getGlobalTypes());
|
|
|
|
}
|
|
|
|
}
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2018-03-23 13:35:54 +00:00
|
|
|
void DwarfDebug::emitSectionReference(const DwarfCompileUnit &CU) {
|
|
|
|
if (useSectionsAsReferences())
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitDwarfOffset(CU.getSection()->getBeginSymbol(),
|
2018-03-23 13:35:54 +00:00
|
|
|
CU.getDebugSectionOffset());
|
|
|
|
else
|
|
|
|
Asm->emitDwarfSymbolReference(CU.getLabelBegin());
|
|
|
|
}
|
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
void DwarfDebug::emitDebugPubSection(bool GnuStyle, StringRef Name,
|
|
|
|
DwarfCompileUnit *TheU,
|
|
|
|
const StringMap<const DIE *> &Globals) {
|
|
|
|
if (auto *Skeleton = TheU->getSkeleton())
|
|
|
|
TheU = Skeleton;
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
// Emit the header.
|
|
|
|
Asm->OutStreamer->AddComment("Length of Public " + Name + " Info");
|
|
|
|
MCSymbol *BeginLabel = Asm->createTempSymbol("pub" + Name + "_begin");
|
|
|
|
MCSymbol *EndLabel = Asm->createTempSymbol("pub" + Name + "_end");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(EndLabel, BeginLabel, 4);
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(BeginLabel);
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("DWARF Version");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt16(dwarf::DW_PUBNAMES_VERSION);
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("Offset of Compilation Unit Info");
|
2018-03-23 13:35:54 +00:00
|
|
|
emitSectionReference(*TheU);
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("Compilation Unit Length");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt32(TheU->getLength());
|
2013-02-12 18:00:14 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
// Emit the pubnames for this compilation unit.
|
|
|
|
for (const auto &GI : Globals) {
|
|
|
|
const char *Name = GI.getKeyData();
|
|
|
|
const DIE *Entity = GI.second;
|
2013-09-13 00:35:05 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("DIE offset");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt32(Entity->getOffset());
|
2017-09-12 21:50:41 +00:00
|
|
|
|
|
|
|
if (GnuStyle) {
|
|
|
|
dwarf::PubIndexEntryDescriptor Desc = computeIndexValue(TheU, Entity);
|
|
|
|
Asm->OutStreamer->AddComment(
|
2018-11-13 20:18:08 +00:00
|
|
|
Twine("Attributes: ") + dwarf::GDBIndexEntryKindString(Desc.Kind) +
|
|
|
|
", " + dwarf::GDBIndexEntryLinkageString(Desc.Linkage));
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt8(Desc.toBits());
|
2013-02-12 18:00:14 +00:00
|
|
|
}
|
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("External Name");
|
2020-02-14 18:16:24 -08:00
|
|
|
Asm->OutStreamer->emitBytes(StringRef(Name, GI.getKeyLength() + 1));
|
2013-02-12 18:00:14 +00:00
|
|
|
}
|
2013-09-13 00:34:58 +00:00
|
|
|
|
2017-09-12 21:50:41 +00:00
|
|
|
Asm->OutStreamer->AddComment("End Mark");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt32(0);
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(EndLabel);
|
2009-11-24 01:14:22 +00:00
|
|
|
}
|
|
|
|
|
2016-01-24 08:18:55 +00:00
|
|
|
/// Emit null-terminated strings into a debug str section.
|
2012-12-27 02:14:01 +00:00
|
|
|
void DwarfDebug::emitDebugStr() {
|
2018-01-26 18:52:58 +00:00
|
|
|
MCSection *StringOffsetsSection = nullptr;
|
|
|
|
if (useSegmentedStringOffsetsTable()) {
|
|
|
|
emitStringOffsetsTableHeader();
|
|
|
|
StringOffsetsSection = Asm->getObjFileLowering().getDwarfStrOffSection();
|
|
|
|
}
|
2013-12-05 18:06:10 +00:00
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
2018-01-26 18:52:58 +00:00
|
|
|
Holder.emitStrings(Asm->getObjFileLowering().getDwarfStrSection(),
|
|
|
|
StringOffsetsSection, /* UseRelativeOffsets = */ true);
|
2012-12-27 02:14:01 +00:00
|
|
|
}
|
|
|
|
|
2019-06-10 08:41:06 +00:00
|
|
|
void DwarfDebug::emitDebugLocEntry(ByteStreamer &Streamer,
|
|
|
|
const DebugLocStream::Entry &Entry,
|
2019-03-19 13:16:28 +00:00
|
|
|
const DwarfCompileUnit *CU) {
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
auto &&Comments = DebugLocs.getComments(Entry);
|
|
|
|
auto Comment = Comments.begin();
|
|
|
|
auto End = Comments.end();
|
2019-03-19 13:16:28 +00:00
|
|
|
|
|
|
|
// The expressions are inserted into a byte stream rather early (see
|
|
|
|
// DwarfExpression::addExpression) so for those ops (e.g. DW_OP_convert) that
|
|
|
|
// need to reference a base_type DIE the offset of that DIE is not yet known.
|
|
|
|
// To deal with this we instead insert a placeholder early and then extract
|
|
|
|
// it here and replace it with the real reference.
|
|
|
|
unsigned PtrSize = Asm->MAI->getCodePointerSize();
|
|
|
|
DWARFDataExtractor Data(StringRef(DebugLocs.getBytes(Entry).data(),
|
|
|
|
DebugLocs.getBytes(Entry).size()),
|
|
|
|
Asm->getDataLayout().isLittleEndian(), PtrSize);
|
2020-05-08 09:28:25 -07:00
|
|
|
DWARFExpression Expr(Data, PtrSize, Asm->OutContext.getDwarfFormat());
|
2019-03-19 13:16:28 +00:00
|
|
|
|
|
|
|
using Encoding = DWARFExpression::Operation::Encoding;
|
2019-08-06 10:49:40 +00:00
|
|
|
uint64_t Offset = 0;
|
2019-03-19 13:16:28 +00:00
|
|
|
for (auto &Op : Expr) {
|
|
|
|
assert(Op.getCode() != dwarf::DW_OP_const_type &&
|
|
|
|
"3 operand ops not yet supported");
|
|
|
|
Streamer.EmitInt8(Op.getCode(), Comment != End ? *(Comment++) : "");
|
|
|
|
Offset++;
|
|
|
|
for (unsigned I = 0; I < 2; ++I) {
|
|
|
|
if (Op.getDescription().Op[I] == Encoding::SizeNA)
|
|
|
|
continue;
|
|
|
|
if (Op.getDescription().Op[I] == Encoding::BaseTypeRef) {
|
2020-02-03 18:47:14 -08:00
|
|
|
uint64_t Offset =
|
|
|
|
CU->ExprRefedBaseTypes[Op.getRawOperand(I)].Die->getOffset();
|
|
|
|
assert(Offset < (1ULL << (ULEB128PadSize * 7)) && "Offset wont fit");
|
2020-02-13 13:26:21 -08:00
|
|
|
Streamer.emitULEB128(Offset, "", ULEB128PadSize);
|
2020-01-31 15:48:18 -08:00
|
|
|
// Make sure comments stay aligned.
|
|
|
|
for (unsigned J = 0; J < ULEB128PadSize; ++J)
|
|
|
|
if (Comment != End)
|
|
|
|
Comment++;
|
2019-03-19 13:16:28 +00:00
|
|
|
} else {
|
2019-08-06 10:49:40 +00:00
|
|
|
for (uint64_t J = Offset; J < Op.getOperandEndOffset(I); ++J)
|
2019-03-19 13:16:28 +00:00
|
|
|
Streamer.EmitInt8(Data.getData()[J], Comment != End ? *(Comment++) : "");
|
|
|
|
}
|
|
|
|
Offset = Op.getOperandEndOffset(I);
|
|
|
|
}
|
|
|
|
assert(Offset == Op.getEndOffset());
|
|
|
|
}
|
2014-08-01 22:11:58 +00:00
|
|
|
}
|
|
|
|
|
2019-06-27 13:52:34 +00:00
|
|
|
void DwarfDebug::emitDebugLocValue(const AsmPrinter &AP, const DIBasicType *BT,
|
|
|
|
const DbgValueLoc &Value,
|
|
|
|
DwarfExpression &DwarfExpr) {
|
2017-03-20 21:35:09 +00:00
|
|
|
auto *DIExpr = Value.getExpression();
|
|
|
|
DIExpressionCursor ExprCursor(DIExpr);
|
|
|
|
DwarfExpr.addFragmentOffset(DIExpr);
|
2014-08-01 22:11:58 +00:00
|
|
|
// Regular entry.
|
2014-04-27 18:25:40 +00:00
|
|
|
if (Value.isInt()) {
|
2015-04-17 16:28:58 +00:00
|
|
|
if (BT && (BT->getEncoding() == dwarf::DW_ATE_signed ||
|
|
|
|
BT->getEncoding() == dwarf::DW_ATE_signed_char))
|
2017-03-16 17:42:45 +00:00
|
|
|
DwarfExpr.addSignedConstant(Value.getInt());
|
2015-01-13 00:04:06 +00:00
|
|
|
else
|
2017-03-16 17:42:45 +00:00
|
|
|
DwarfExpr.addUnsignedConstant(Value.getInt());
|
2014-04-27 18:25:40 +00:00
|
|
|
} else if (Value.isLocation()) {
|
2017-03-20 21:35:09 +00:00
|
|
|
MachineLocation Location = Value.getLoc();
|
2020-05-20 15:30:58 -07:00
|
|
|
DwarfExpr.setLocation(Location, DIExpr);
|
2017-08-02 15:22:17 +00:00
|
|
|
DIExpressionCursor Cursor(DIExpr);
|
2019-06-27 13:52:34 +00:00
|
|
|
|
2020-05-20 15:30:58 -07:00
|
|
|
if (DIExpr->isEntryValue())
|
[DebugInfo] Add a DW_OP_LLVM_entry_value operation
Summary:
Internally in LLVM's metadata we use DW_OP_entry_value operations with
the same semantics as DWARF; that is, its operand specifies the number
of bytes that the entry value covers.
At the time of emitting entry values we don't know the emitted size of
the DWARF expression that the entry value will cover. Currently the size
is hardcoded to 1 in DIExpression, and other values causes the verifier
to fail. As the size is 1, that effectively means that we can only have
valid entry values for registers that can be encoded in one byte, which
are the registers with DWARF numbers 0 to 31 (as they can be encoded as
single-byte DW_OP_reg0..DW_OP_reg31 rather than a multi-byte
DW_OP_regx). It is a bit confusing, but it seems like llvm-dwarfdump
will print an operation "correctly", even if the byte size is less than
that, which may make it seem that we emit correct DWARF for registers
with DWARF numbers > 31. If you instead use readelf for such cases, it
will interpret the number of specified bytes as a DWARF expression. This
seems like a limitation in llvm-dwarfdump.
As suggested in D66746, a way forward would be to add an internal
variant of DW_OP_entry_value, DW_OP_LLVM_entry_value, whose operand
instead specifies the number of operations that the entry value covers,
and we then translate that into the byte size at the time of emission.
In this patch that internal operation is added. This patch keeps the
limitation that a entry value can only be applied to simple register
locations, but it will fix the issue with the size operand being
incorrect for DWARF numbers > 31.
Reviewers: aprantl, vsk, djtodoro, NikolaPrica
Reviewed By: aprantl
Subscribers: jyknight, fedor.sergeev, hiraditya, llvm-commits
Tags: #debug-info, #llvm
Differential Revision: https://reviews.llvm.org/D67492
llvm-svn: 374881
2019-10-15 11:31:21 +00:00
|
|
|
DwarfExpr.beginEntryValueExpression(Cursor);
|
2019-06-27 13:52:34 +00:00
|
|
|
|
2016-12-09 20:43:40 +00:00
|
|
|
const TargetRegisterInfo &TRI = *AP.MF->getSubtarget().getRegisterInfo();
|
2017-04-19 23:42:25 +00:00
|
|
|
if (!DwarfExpr.addMachineRegExpression(TRI, Cursor, Location.getReg()))
|
2017-03-20 21:35:09 +00:00
|
|
|
return;
|
|
|
|
return DwarfExpr.addExpression(std::move(Cursor));
|
2019-12-20 14:31:56 -08:00
|
|
|
} else if (Value.isTargetIndexLocation()) {
|
|
|
|
TargetIndexLocation Loc = Value.getTargetIndexLocation();
|
|
|
|
// TODO TargetIndexLocation is a target-independent. Currently only the WebAssembly-specific
|
|
|
|
// encoding is supported.
|
2020-03-19 19:53:51 -07:00
|
|
|
DwarfExpr.addWasmLocation(Loc.Index, static_cast<uint64_t>(Loc.Offset));
|
2016-04-08 00:38:37 +00:00
|
|
|
} else if (Value.isConstantFP()) {
|
|
|
|
APInt RawBytes = Value.getConstantFP()->getValueAPF().bitcastToAPInt();
|
2017-03-16 17:42:45 +00:00
|
|
|
DwarfExpr.addUnsignedConstant(RawBytes);
|
2014-03-07 22:40:37 +00:00
|
|
|
}
|
2017-03-16 17:42:45 +00:00
|
|
|
DwarfExpr.addExpression(std::move(ExprCursor));
|
2014-03-07 22:40:37 +00:00
|
|
|
}
|
|
|
|
|
2015-06-21 16:54:56 +00:00
|
|
|
void DebugLocEntry::finalize(const AsmPrinter &AP,
|
|
|
|
DebugLocStream::ListBuilder &List,
|
2019-03-19 13:16:28 +00:00
|
|
|
const DIBasicType *BT,
|
|
|
|
DwarfCompileUnit &TheCU) {
|
2019-04-09 10:08:26 +00:00
|
|
|
assert(!Values.empty() &&
|
|
|
|
"location list entries without values are redundant");
|
[DebugInfo] Omit location list entries with empty ranges
Summary:
This fixes PR39710. In that case we emitted a location list looking like
this:
.Ldebug_loc0:
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_begin0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # DW_OP_reg5
.quad .Lfunc_begin0-.Lfunc_begin0
.quad .Lfunc_end0-.Lfunc_begin0
.short 1 # Loc expr size
.byte 85 # super-register DW_OP_reg5
.quad 0
.quad 0
As seen, the first entry's beginning and ending addresses evalute to 0,
which meant that the entry inadvertently became an "end of list" entry,
resulting in the location list ending sooner than expected.
To fix this, omit all entries with empty ranges. Location list entries
with empty ranges do not have any effect, as specified by DWARF, so we
might as well drop them:
"A location list entry (but not a base address selection or end of list
entry) whose beginning and ending addresses are equal has no effect
because the size of the range covered by such an entry is zero."
Reviewers: davide, aprantl, dblaikie
Reviewed By: aprantl
Subscribers: javed.absar, JDevlieghere, llvm-commits
Tags: #debug-info
Differential Revision: https://reviews.llvm.org/D55919
llvm-svn: 350698
2019-01-09 09:58:59 +00:00
|
|
|
assert(Begin != End && "unexpected location list entry with empty range");
|
2015-06-21 16:54:56 +00:00
|
|
|
DebugLocStream::EntryBuilder Entry(List, Begin, End);
|
|
|
|
BufferByteStreamer Streamer = Entry.getStreamer();
|
2019-03-19 13:16:28 +00:00
|
|
|
DebugLocDwarfExpression DwarfExpr(AP.getDwarfVersion(), Streamer, TheCU);
|
2019-06-13 10:23:26 +00:00
|
|
|
const DbgValueLoc &Value = Values[0];
|
2016-12-05 18:04:47 +00:00
|
|
|
if (Value.isFragment()) {
|
|
|
|
// Emit all fragments that belong to the same variable and range.
|
2019-06-13 10:23:26 +00:00
|
|
|
assert(llvm::all_of(Values, [](DbgValueLoc P) {
|
2016-12-05 18:04:47 +00:00
|
|
|
return P.isFragment();
|
|
|
|
}) && "all values are expected to be fragments");
|
2020-04-13 14:46:41 +03:00
|
|
|
assert(llvm::is_sorted(Values) && "fragments are expected to be sorted");
|
2015-04-13 18:53:11 +00:00
|
|
|
|
2016-12-09 20:43:40 +00:00
|
|
|
for (auto Fragment : Values)
|
2019-06-27 13:52:34 +00:00
|
|
|
DwarfDebug::emitDebugLocValue(AP, BT, Fragment, DwarfExpr);
|
2016-12-09 20:43:40 +00:00
|
|
|
|
2015-03-02 22:02:33 +00:00
|
|
|
} else {
|
2016-12-05 18:04:47 +00:00
|
|
|
assert(Values.size() == 1 && "only fragments may have >1 value");
|
2019-06-27 13:52:34 +00:00
|
|
|
DwarfDebug::emitDebugLocValue(AP, BT, Value, DwarfExpr);
|
2015-03-02 22:02:33 +00:00
|
|
|
}
|
2016-12-09 20:43:40 +00:00
|
|
|
DwarfExpr.finalize();
|
2019-11-25 17:47:30 -08:00
|
|
|
if (DwarfExpr.TagOffset)
|
|
|
|
List.setTagOffset(*DwarfExpr.TagOffset);
|
2015-03-02 22:02:33 +00:00
|
|
|
}
|
|
|
|
|
2019-03-19 13:16:28 +00:00
|
|
|
void DwarfDebug::emitDebugLocEntryLocation(const DebugLocStream::Entry &Entry,
|
|
|
|
const DwarfCompileUnit *CU) {
|
2015-05-06 19:11:20 +00:00
|
|
|
// Emit the size.
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("Loc expr size");
|
2019-02-01 17:11:58 +00:00
|
|
|
if (getDwarfVersion() >= 5)
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(DebugLocs.getBytes(Entry).size());
|
2019-03-19 20:37:06 +00:00
|
|
|
else if (DebugLocs.getBytes(Entry).size() <= std::numeric_limits<uint16_t>::max())
|
2019-02-01 17:11:58 +00:00
|
|
|
Asm->emitInt16(DebugLocs.getBytes(Entry).size());
|
2019-03-19 20:37:06 +00:00
|
|
|
else {
|
|
|
|
// The entry is too big to fit into 16 bit, drop it as there is nothing we
|
|
|
|
// can do.
|
|
|
|
Asm->emitInt16(0);
|
|
|
|
return;
|
|
|
|
}
|
2014-04-01 16:17:41 +00:00
|
|
|
// Emit the entry.
|
|
|
|
APByteStreamer Streamer(*Asm);
|
2019-03-19 13:16:28 +00:00
|
|
|
emitDebugLocEntry(Streamer, Entry, CU);
|
2014-04-01 16:17:41 +00:00
|
|
|
}
|
|
|
|
|
2018-10-26 11:25:12 +00:00
|
|
|
// Emit the header of a DWARF 5 range list table list table. Returns the symbol
|
|
|
|
// that designates the end of the table for the caller to emit when the table is
|
|
|
|
// complete.
|
|
|
|
static MCSymbol *emitRnglistsTableHeader(AsmPrinter *Asm,
|
|
|
|
const DwarfFile &Holder) {
|
2020-03-03 13:58:02 -08:00
|
|
|
MCSymbol *TableEnd = mcdwarf::emitListsTableHeaderStart(*Asm->OutStreamer);
|
2018-10-26 11:25:12 +00:00
|
|
|
|
|
|
|
Asm->OutStreamer->AddComment("Offset entry count");
|
|
|
|
Asm->emitInt32(Holder.getRangeLists().size());
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(Holder.getRnglistsTableBaseSym());
|
2018-10-26 11:25:12 +00:00
|
|
|
|
|
|
|
for (const RangeSpanList &List : Holder.getRangeLists())
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(List.Label, Holder.getRnglistsTableBaseSym(), 4);
|
2018-10-26 11:25:12 +00:00
|
|
|
|
|
|
|
return TableEnd;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Emit the header of a DWARF 5 locations list table. Returns the symbol that
|
|
|
|
// designates the end of the table for the caller to emit when the table is
|
|
|
|
// complete.
|
|
|
|
static MCSymbol *emitLoclistsTableHeader(AsmPrinter *Asm,
|
2019-10-17 23:02:19 +00:00
|
|
|
const DwarfDebug &DD) {
|
2020-03-03 13:58:02 -08:00
|
|
|
MCSymbol *TableEnd = mcdwarf::emitListsTableHeaderStart(*Asm->OutStreamer);
|
2018-10-26 11:25:12 +00:00
|
|
|
|
2019-10-17 23:02:19 +00:00
|
|
|
const auto &DebugLocs = DD.getDebugLocs();
|
|
|
|
|
2018-10-26 11:25:12 +00:00
|
|
|
Asm->OutStreamer->AddComment("Offset entry count");
|
2019-11-12 14:15:37 -08:00
|
|
|
Asm->emitInt32(DebugLocs.getLists().size());
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(DebugLocs.getSym());
|
2018-10-26 11:25:12 +00:00
|
|
|
|
2019-11-12 14:15:37 -08:00
|
|
|
for (const auto &List : DebugLocs.getLists())
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(List.Label, DebugLocs.getSym(), 4);
|
2019-11-12 14:15:37 -08:00
|
|
|
|
2018-10-26 11:25:12 +00:00
|
|
|
return TableEnd;
|
|
|
|
}
|
|
|
|
|
2019-10-11 21:52:41 +00:00
|
|
|
template <typename Ranges, typename PayloadEmitter>
|
|
|
|
static void emitRangeList(
|
|
|
|
DwarfDebug &DD, AsmPrinter *Asm, MCSymbol *Sym, const Ranges &R,
|
|
|
|
const DwarfCompileUnit &CU, unsigned BaseAddressx, unsigned OffsetPair,
|
|
|
|
unsigned StartxLength, unsigned EndOfList,
|
|
|
|
StringRef (*StringifyEnum)(unsigned),
|
|
|
|
bool ShouldUseBaseAddress,
|
|
|
|
PayloadEmitter EmitPayload) {
|
|
|
|
|
|
|
|
auto Size = Asm->MAI->getCodePointerSize();
|
|
|
|
bool UseDwarf5 = DD.getDwarfVersion() >= 5;
|
|
|
|
|
|
|
|
// Emit our symbol so we can find the beginning of the range.
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(Sym);
|
2019-10-11 21:52:41 +00:00
|
|
|
|
|
|
|
// Gather all the ranges that apply to the same section so they can share
|
|
|
|
// a base address entry.
|
|
|
|
MapVector<const MCSection *, std::vector<decltype(&*R.begin())>> SectionRanges;
|
|
|
|
|
|
|
|
for (const auto &Range : R)
|
|
|
|
SectionRanges[&Range.Begin->getSection()].push_back(&Range);
|
|
|
|
|
|
|
|
const MCSymbol *CUBase = CU.getBaseAddress();
|
|
|
|
bool BaseIsSet = false;
|
|
|
|
for (const auto &P : SectionRanges) {
|
|
|
|
auto *Base = CUBase;
|
|
|
|
if (!Base && ShouldUseBaseAddress) {
|
|
|
|
const MCSymbol *Begin = P.second.front()->Begin;
|
|
|
|
const MCSymbol *NewBase = DD.getSectionLabel(&Begin->getSection());
|
|
|
|
if (!UseDwarf5) {
|
|
|
|
Base = NewBase;
|
|
|
|
BaseIsSet = true;
|
2020-02-14 22:40:47 -08:00
|
|
|
Asm->OutStreamer->emitIntValue(-1, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
Asm->OutStreamer->AddComment(" base address");
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitSymbolValue(Base, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
} else if (NewBase != Begin || P.second.size() > 1) {
|
|
|
|
// Only use a base address if
|
|
|
|
// * the existing pool address doesn't match (NewBase != Begin)
|
|
|
|
// * or, there's more than one entry to share the base address
|
|
|
|
Base = NewBase;
|
|
|
|
BaseIsSet = true;
|
|
|
|
Asm->OutStreamer->AddComment(StringifyEnum(BaseAddressx));
|
|
|
|
Asm->emitInt8(BaseAddressx);
|
|
|
|
Asm->OutStreamer->AddComment(" base address index");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(DD.getAddressPool().getIndex(Base));
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
} else if (BaseIsSet && !UseDwarf5) {
|
|
|
|
BaseIsSet = false;
|
|
|
|
assert(!Base);
|
2020-02-14 22:40:47 -08:00
|
|
|
Asm->OutStreamer->emitIntValue(-1, Size);
|
|
|
|
Asm->OutStreamer->emitIntValue(0, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (const auto *RS : P.second) {
|
|
|
|
const MCSymbol *Begin = RS->Begin;
|
|
|
|
const MCSymbol *End = RS->End;
|
|
|
|
assert(Begin && "Range without a begin symbol?");
|
|
|
|
assert(End && "Range without an end symbol?");
|
|
|
|
if (Base) {
|
|
|
|
if (UseDwarf5) {
|
|
|
|
// Emit offset_pair when we have a base.
|
|
|
|
Asm->OutStreamer->AddComment(StringifyEnum(OffsetPair));
|
|
|
|
Asm->emitInt8(OffsetPair);
|
|
|
|
Asm->OutStreamer->AddComment(" starting offset");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifferenceAsULEB128(Begin, Base);
|
2019-10-11 21:52:41 +00:00
|
|
|
Asm->OutStreamer->AddComment(" ending offset");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifferenceAsULEB128(End, Base);
|
2019-10-11 21:52:41 +00:00
|
|
|
} else {
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(Begin, Base, Size);
|
|
|
|
Asm->emitLabelDifference(End, Base, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
} else if (UseDwarf5) {
|
|
|
|
Asm->OutStreamer->AddComment(StringifyEnum(StartxLength));
|
|
|
|
Asm->emitInt8(StartxLength);
|
|
|
|
Asm->OutStreamer->AddComment(" start index");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(DD.getAddressPool().getIndex(Begin));
|
2019-10-11 21:52:41 +00:00
|
|
|
Asm->OutStreamer->AddComment(" length");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifferenceAsULEB128(End, Begin);
|
2019-10-11 21:52:41 +00:00
|
|
|
} else {
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitSymbolValue(Begin, Size);
|
|
|
|
Asm->OutStreamer->emitSymbolValue(End, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
EmitPayload(*RS);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (UseDwarf5) {
|
|
|
|
Asm->OutStreamer->AddComment(StringifyEnum(EndOfList));
|
|
|
|
Asm->emitInt8(EndOfList);
|
|
|
|
} else {
|
|
|
|
// Terminate the list with two 0 values.
|
2020-02-14 22:40:47 -08:00
|
|
|
Asm->OutStreamer->emitIntValue(0, Size);
|
|
|
|
Asm->OutStreamer->emitIntValue(0, Size);
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-23 20:04:36 +05:30
|
|
|
// Handles emission of both debug_loclist / debug_loclist.dwo
|
2019-10-11 21:52:41 +00:00
|
|
|
static void emitLocList(DwarfDebug &DD, AsmPrinter *Asm, const DebugLocStream::List &List) {
|
2019-11-23 20:04:36 +05:30
|
|
|
emitRangeList(DD, Asm, List.Label, DD.getDebugLocs().getEntries(List),
|
|
|
|
*List.CU, dwarf::DW_LLE_base_addressx,
|
|
|
|
dwarf::DW_LLE_offset_pair, dwarf::DW_LLE_startx_length,
|
|
|
|
dwarf::DW_LLE_end_of_list, llvm::dwarf::LocListEncodingString,
|
|
|
|
/* ShouldUseBaseAddress */ true,
|
|
|
|
[&](const DebugLocStream::Entry &E) {
|
|
|
|
DD.emitDebugLocEntryLocation(E, List.CU);
|
|
|
|
});
|
2019-10-11 21:52:41 +00:00
|
|
|
}
|
|
|
|
|
2019-12-12 16:37:52 -08:00
|
|
|
void DwarfDebug::emitDebugLocImpl(MCSection *Sec) {
|
2017-05-26 18:52:56 +00:00
|
|
|
if (DebugLocs.getLists().empty())
|
|
|
|
return;
|
|
|
|
|
2019-12-12 16:37:52 -08:00
|
|
|
Asm->OutStreamer->SwitchSection(Sec);
|
2019-11-23 20:04:36 +05:30
|
|
|
|
2019-12-12 16:37:52 -08:00
|
|
|
MCSymbol *TableEnd = nullptr;
|
|
|
|
if (getDwarfVersion() >= 5)
|
2019-10-17 23:02:19 +00:00
|
|
|
TableEnd = emitLoclistsTableHeader(Asm, *this);
|
2018-10-26 11:25:12 +00:00
|
|
|
|
2019-10-11 21:52:41 +00:00
|
|
|
for (const auto &List : DebugLocs.getLists())
|
|
|
|
emitLocList(*this, Asm, List);
|
2018-10-26 11:25:12 +00:00
|
|
|
|
|
|
|
if (TableEnd)
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(TableEnd);
|
2014-04-02 01:50:20 +00:00
|
|
|
}
|
|
|
|
|
2019-12-12 16:37:52 -08:00
|
|
|
// Emit locations into the .debug_loc/.debug_loclists section.
|
|
|
|
void DwarfDebug::emitDebugLoc() {
|
|
|
|
emitDebugLocImpl(
|
|
|
|
getDwarfVersion() >= 5
|
|
|
|
? Asm->getObjFileLowering().getDwarfLoclistsSection()
|
|
|
|
: Asm->getObjFileLowering().getDwarfLocSection());
|
|
|
|
}
|
|
|
|
|
2019-11-23 20:04:36 +05:30
|
|
|
// Emit locations into the .debug_loc.dwo/.debug_loclists.dwo section.
|
2014-04-02 01:50:20 +00:00
|
|
|
void DwarfDebug::emitDebugLocDWO() {
|
2019-11-23 20:04:36 +05:30
|
|
|
if (getDwarfVersion() >= 5) {
|
2019-12-12 16:37:52 -08:00
|
|
|
emitDebugLocImpl(
|
2019-11-23 20:04:36 +05:30
|
|
|
Asm->getObjFileLowering().getDwarfLoclistsDWOSection());
|
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
for (const auto &List : DebugLocs.getLists()) {
|
2019-02-12 00:00:38 +00:00
|
|
|
Asm->OutStreamer->SwitchSection(
|
|
|
|
Asm->getObjFileLowering().getDwarfLocDWOSection());
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(List.Label);
|
2019-11-23 20:04:36 +05:30
|
|
|
|
AsmPrinter: Create a unified .debug_loc stream
This commit removes `DebugLocList` and replaces it with
`DebugLocStream`.
- `DebugLocEntry` no longer contains its byte/comment streams.
- The `DebugLocEntry` list for a variable/inlined-at pair is allocated
on the stack, and released right after `DebugLocEntry::finalize()`
(possible because of the refactoring in r231023). Now, only one
list is in memory at a time now.
- There's a single unified stream for the `.debug_loc` section that
persists, stored in the new `DebugLocStream` data structure.
The last point is important: this collapses the nested `SmallVector<>`s
from `DebugLocList` into unified streams. We previously had something
like the following:
vec<tuple<Label, CU,
vec<tuple<BeginSym, EndSym,
vec<Value>,
vec<char>,
vec<string>>>>>
A `SmallVector` can avoid allocations, but is statically fairly large
for a vector: three pointers plus the size of the small storage, which
is the number of elements in small mode times the element size).
Nesting these is expensive, since an inner vector's size contributes to
the element size of an outer one. (Nesting any vector is expensive...)
In the old data structure, the outer vector's *element* size was 632B,
excluding allocation costs for when the middle and inner vectors
exceeded their small sizes. 312B of this was for the "three" pointers
in the vector-tree beneath it. If you assume 1M functions with an
average of 10 variable/inlined-at pairs each (in an LTO scenario),
that's almost 6GB (besides inner allocations), with almost 3GB for the
"three" pointers.
This came up in a heap profile a little while ago of a `clang -flto -g`
bootstrap, with `DwarfDebug::collectVariableInfo()` using something like
10-15% of the total memory.
With this commit, we have:
tuple<vec<tuple<Label, CU, Offset>>,
vec<tuple<BeginSym, EndSym, Offset, Offset>>,
vec<char>,
vec<string>>
The offsets are used to create `ArrayRef` slices of adjacent
`SmallVector`s. This reduces the number of vectors to four (unrelated
to the number of variable/inlined-at pairs), and caps the number of
allocations at the same number.
Besides saving memory and limiting allocations, this is NFC.
I don't know my way around this code very well yet, but I wonder if we
could go further: why stream to a side-table, instead of directly to the
output stream?
llvm-svn: 235229
2015-04-17 21:34:47 +00:00
|
|
|
for (const auto &Entry : DebugLocs.getEntries(List)) {
|
2018-10-25 22:26:25 +00:00
|
|
|
// GDB only supports startx_length in pre-standard split-DWARF.
|
|
|
|
// (in v5 standard loclists, it currently* /only/ supports base_address +
|
|
|
|
// offset_pair, so the implementations can't really share much since they
|
|
|
|
// need to use different representations)
|
|
|
|
// * as of October 2018, at least
|
2020-01-17 18:12:34 -08:00
|
|
|
//
|
|
|
|
// In v5 (see emitLocList), this uses SectionLabels to reuse existing
|
|
|
|
// addresses in the address pool to minimize object size/relocations.
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt8(dwarf::DW_LLE_startx_length);
|
2019-10-02 22:58:02 +00:00
|
|
|
unsigned idx = AddrPool.getIndex(Entry.Begin);
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(idx);
|
2019-12-10 14:10:15 -08:00
|
|
|
// Also the pre-standard encoding is slightly different, emitting this as
|
|
|
|
// an address-length entry here, but its a ULEB128 in DWARFv5 loclists.
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(Entry.End, Entry.Begin, 4);
|
2019-03-19 13:16:28 +00:00
|
|
|
emitDebugLocEntryLocation(Entry, List.CU);
|
2014-03-25 01:44:02 +00:00
|
|
|
}
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt8(dwarf::DW_LLE_end_of_list);
|
2010-05-25 23:40:22 +00:00
|
|
|
}
|
2009-05-20 23:21:38 +00:00
|
|
|
}
|
2009-05-15 09:23:25 +00:00
|
|
|
|
2013-09-19 23:21:01 +00:00
|
|
|
struct ArangeSpan {
|
|
|
|
const MCSymbol *Start, *End;
|
|
|
|
};
|
|
|
|
|
|
|
|
// Emit a debug aranges section, containing a CU lookup for any
|
|
|
|
// address we can tie back to a CU.
|
2012-11-21 00:34:35 +00:00
|
|
|
void DwarfDebug::emitDebugARanges() {
|
2015-02-26 22:02:02 +00:00
|
|
|
// Provides a unique id per text section.
|
2015-05-21 19:20:38 +00:00
|
|
|
MapVector<MCSection *, SmallVector<SymbolCU, 8>> SectionMap;
|
2013-09-19 23:21:01 +00:00
|
|
|
|
2015-02-26 22:02:02 +00:00
|
|
|
// Filter labels by section.
|
|
|
|
for (const SymbolCU &SCU : ArangeLabels) {
|
|
|
|
if (SCU.Sym->isInSection()) {
|
|
|
|
// Make a note of this symbol and it's section.
|
2015-05-21 19:20:38 +00:00
|
|
|
MCSection *Section = &SCU.Sym->getSection();
|
2015-02-26 22:02:02 +00:00
|
|
|
if (!Section->getKind().isMetadata())
|
|
|
|
SectionMap[Section].push_back(SCU);
|
|
|
|
} else {
|
|
|
|
// Some symbols (e.g. common/bss on mach-o) can have no section but still
|
|
|
|
// appear in the output. This sucks as we rely on sections to build
|
|
|
|
// arange spans. We can do it without, but it's icky.
|
|
|
|
SectionMap[nullptr].push_back(SCU);
|
|
|
|
}
|
|
|
|
}
|
2013-09-19 23:21:01 +00:00
|
|
|
|
2015-02-26 22:02:02 +00:00
|
|
|
DenseMap<DwarfCompileUnit *, std::vector<ArangeSpan>> Spans;
|
|
|
|
|
2015-03-09 22:08:37 +00:00
|
|
|
for (auto &I : SectionMap) {
|
2016-05-20 00:38:28 +00:00
|
|
|
MCSection *Section = I.first;
|
2015-03-09 22:08:37 +00:00
|
|
|
SmallVector<SymbolCU, 8> &List = I.second;
|
2016-05-20 00:38:28 +00:00
|
|
|
if (List.size() < 1)
|
2013-09-19 23:21:01 +00:00
|
|
|
continue;
|
|
|
|
|
2015-02-02 19:22:51 +00:00
|
|
|
// If we have no section (e.g. common), just write out
|
|
|
|
// individual spans for each symbol.
|
|
|
|
if (!Section) {
|
|
|
|
for (const SymbolCU &Cur : List) {
|
|
|
|
ArangeSpan Span;
|
|
|
|
Span.Start = Cur.Sym;
|
|
|
|
Span.End = nullptr;
|
2016-05-20 00:38:28 +00:00
|
|
|
assert(Cur.CU);
|
|
|
|
Spans[Cur.CU].push_back(Span);
|
2015-02-02 19:22:51 +00:00
|
|
|
}
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2013-09-19 23:21:01 +00:00
|
|
|
// Sort the symbols by offset within the section.
|
2019-04-23 14:51:27 +00:00
|
|
|
llvm::stable_sort(List, [&](const SymbolCU &A, const SymbolCU &B) {
|
|
|
|
unsigned IA = A.Sym ? Asm->OutStreamer->GetSymbolOrder(A.Sym) : 0;
|
|
|
|
unsigned IB = B.Sym ? Asm->OutStreamer->GetSymbolOrder(B.Sym) : 0;
|
|
|
|
|
|
|
|
// Symbols with no order assigned should be placed at the end.
|
|
|
|
// (e.g. section end labels)
|
|
|
|
if (IA == 0)
|
|
|
|
return false;
|
|
|
|
if (IB == 0)
|
|
|
|
return true;
|
|
|
|
return IA < IB;
|
|
|
|
});
|
2013-09-19 23:21:01 +00:00
|
|
|
|
2016-05-20 00:38:28 +00:00
|
|
|
// Insert a final terminator.
|
|
|
|
List.push_back(SymbolCU(nullptr, Asm->OutStreamer->endSection(Section)));
|
|
|
|
|
2015-02-02 19:22:51 +00:00
|
|
|
// Build spans between each label.
|
|
|
|
const MCSymbol *StartSym = List[0].Sym;
|
|
|
|
for (size_t n = 1, e = List.size(); n < e; n++) {
|
|
|
|
const SymbolCU &Prev = List[n - 1];
|
|
|
|
const SymbolCU &Cur = List[n];
|
|
|
|
|
|
|
|
// Try and build the longest span we can within the same CU.
|
|
|
|
if (Cur.CU != Prev.CU) {
|
2013-09-19 23:21:01 +00:00
|
|
|
ArangeSpan Span;
|
2015-02-02 19:22:51 +00:00
|
|
|
Span.Start = StartSym;
|
|
|
|
Span.End = Cur.Sym;
|
2016-05-20 00:38:28 +00:00
|
|
|
assert(Prev.CU);
|
2015-02-02 19:22:51 +00:00
|
|
|
Spans[Prev.CU].push_back(Span);
|
|
|
|
StartSym = Cur.Sym;
|
2013-09-19 23:21:01 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-02-26 22:02:02 +00:00
|
|
|
// Start the dwarf aranges section.
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->SwitchSection(
|
2015-02-26 22:02:02 +00:00
|
|
|
Asm->getObjFileLowering().getDwarfARangesSection());
|
|
|
|
|
2017-04-17 17:41:25 +00:00
|
|
|
unsigned PtrSize = Asm->MAI->getCodePointerSize();
|
2013-09-19 23:21:01 +00:00
|
|
|
|
|
|
|
// Build a list of CUs used.
|
2013-12-09 23:57:44 +00:00
|
|
|
std::vector<DwarfCompileUnit *> CUs;
|
2014-03-07 19:09:39 +00:00
|
|
|
for (const auto &it : Spans) {
|
|
|
|
DwarfCompileUnit *CU = it.first;
|
2013-09-19 23:21:01 +00:00
|
|
|
CUs.push_back(CU);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Sort the CU list (again, to ensure consistent output order).
|
llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)
Summary: The convenience wrapper in STLExtras is available since rL342102.
Reviewers: dblaikie, javed.absar, JDevlieghere, andreadb
Subscribers: MatzeB, sanjoy, arsenm, dschuff, mehdi_amini, sdardis, nemanjai, jvesely, nhaehnle, sbc100, jgravelle-google, eraman, aheejin, kbarton, JDevlieghere, javed.absar, gbedwell, jrtc27, mgrang, atanasyan, steven_wu, george.burgess.iv, dexonsmith, kristina, jsji, llvm-commits
Differential Revision: https://reviews.llvm.org/D52573
llvm-svn: 343163
2018-09-27 02:13:45 +00:00
|
|
|
llvm::sort(CUs, [](const DwarfCompileUnit *A, const DwarfCompileUnit *B) {
|
|
|
|
return A->getUniqueID() < B->getUniqueID();
|
|
|
|
});
|
2013-09-19 23:21:01 +00:00
|
|
|
|
|
|
|
// Emit an arange table for each CU we used.
|
2014-03-07 19:09:39 +00:00
|
|
|
for (DwarfCompileUnit *CU : CUs) {
|
2013-09-19 23:21:01 +00:00
|
|
|
std::vector<ArangeSpan> &List = Spans[CU];
|
|
|
|
|
2014-11-02 01:21:43 +00:00
|
|
|
// Describe the skeleton CU's offset and length, not the dwo file's.
|
|
|
|
if (auto *Skel = CU->getSkeleton())
|
|
|
|
CU = Skel;
|
|
|
|
|
2013-09-19 23:21:01 +00:00
|
|
|
// Emit size of content not including length itself.
|
2013-11-19 09:04:36 +00:00
|
|
|
unsigned ContentSize =
|
|
|
|
sizeof(int16_t) + // DWARF ARange version number
|
|
|
|
sizeof(int32_t) + // Offset of CU in the .debug_info section
|
|
|
|
sizeof(int8_t) + // Pointer Size (in bytes)
|
|
|
|
sizeof(int8_t); // Segment Size (in bytes)
|
2013-09-19 23:21:01 +00:00
|
|
|
|
|
|
|
unsigned TupleSize = PtrSize * 2;
|
|
|
|
|
|
|
|
// 7.20 in the Dwarf specs requires the table to be aligned to a tuple.
|
2019-09-27 12:54:21 +00:00
|
|
|
unsigned Padding =
|
|
|
|
offsetToAlignment(sizeof(int32_t) + ContentSize, Align(TupleSize));
|
2013-09-19 23:21:01 +00:00
|
|
|
|
|
|
|
ContentSize += Padding;
|
|
|
|
ContentSize += (List.size() + 1) * TupleSize;
|
|
|
|
|
|
|
|
// For each compile unit, write the list of spans it covers.
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("Length of ARange Set");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt32(ContentSize);
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("DWARF Arange version number");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt16(dwarf::DW_ARANGES_VERSION);
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("Offset Into Debug Info Section");
|
2018-03-23 13:35:54 +00:00
|
|
|
emitSectionReference(*CU);
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("Address Size (in bytes)");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt8(PtrSize);
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("Segment Size (in bytes)");
|
2018-03-29 23:32:54 +00:00
|
|
|
Asm->emitInt8(0);
|
2013-09-19 23:21:01 +00:00
|
|
|
|
2016-06-01 01:59:58 +00:00
|
|
|
Asm->OutStreamer->emitFill(Padding, 0xff);
|
2013-09-19 23:21:01 +00:00
|
|
|
|
2014-03-07 19:09:39 +00:00
|
|
|
for (const ArangeSpan &Span : List) {
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelReference(Span.Start, PtrSize);
|
2013-09-19 23:21:01 +00:00
|
|
|
|
|
|
|
// Calculate the size as being from the span start to it's end.
|
2013-09-23 17:56:20 +00:00
|
|
|
if (Span.End) {
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitLabelDifference(Span.End, Span.Start, PtrSize);
|
2013-09-23 17:56:20 +00:00
|
|
|
} else {
|
|
|
|
// For symbols without an end marker (e.g. common), we
|
|
|
|
// write a single arange entry containing just that one symbol.
|
|
|
|
uint64_t Size = SymSize[Span.Start];
|
|
|
|
if (Size == 0)
|
|
|
|
Size = 1;
|
|
|
|
|
2020-02-14 22:40:47 -08:00
|
|
|
Asm->OutStreamer->emitIntValue(Size, PtrSize);
|
2013-09-23 17:56:20 +00:00
|
|
|
}
|
2013-09-19 23:21:01 +00:00
|
|
|
}
|
|
|
|
|
2015-04-24 19:11:51 +00:00
|
|
|
Asm->OutStreamer->AddComment("ARange terminator");
|
2020-02-14 22:40:47 -08:00
|
|
|
Asm->OutStreamer->emitIntValue(0, PtrSize);
|
|
|
|
Asm->OutStreamer->emitIntValue(0, PtrSize);
|
2013-09-19 23:21:01 +00:00
|
|
|
}
|
2009-05-20 23:04:56 +00:00
|
|
|
}
|
|
|
|
|
2019-10-03 20:56:23 +00:00
|
|
|
/// Emit a single range list. We handle both DWARF v5 and earlier.
|
|
|
|
static void emitRangeList(DwarfDebug &DD, AsmPrinter *Asm,
|
|
|
|
const RangeSpanList &List) {
|
2019-12-16 15:19:25 -08:00
|
|
|
emitRangeList(DD, Asm, List.Label, List.Ranges, *List.CU,
|
2019-10-03 20:56:23 +00:00
|
|
|
dwarf::DW_RLE_base_addressx, dwarf::DW_RLE_offset_pair,
|
|
|
|
dwarf::DW_RLE_startx_length, dwarf::DW_RLE_end_of_list,
|
2019-10-11 21:52:41 +00:00
|
|
|
llvm::dwarf::RangeListEncodingString,
|
2019-12-16 15:19:25 -08:00
|
|
|
List.CU->getCUNode()->getRangesBaseAddress() ||
|
2019-10-11 21:52:41 +00:00
|
|
|
DD.getDwarfVersion() >= 5,
|
|
|
|
[](auto) {});
|
2019-10-03 20:56:23 +00:00
|
|
|
}
|
|
|
|
|
2019-11-01 14:50:12 -07:00
|
|
|
void DwarfDebug::emitDebugRangesImpl(const DwarfFile &Holder, MCSection *Section) {
|
|
|
|
if (Holder.getRangeLists().empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
assert(useRangesSection());
|
|
|
|
assert(!CUMap.empty());
|
|
|
|
assert(llvm::any_of(CUMap, [](const decltype(CUMap)::value_type &Pair) {
|
|
|
|
return !Pair.second->getCUNode()->isDebugDirectivesOnly();
|
|
|
|
}));
|
|
|
|
|
|
|
|
Asm->OutStreamer->SwitchSection(Section);
|
|
|
|
|
2019-12-16 15:19:25 -08:00
|
|
|
MCSymbol *TableEnd = nullptr;
|
|
|
|
if (getDwarfVersion() >= 5)
|
|
|
|
TableEnd = emitRnglistsTableHeader(Asm, Holder);
|
2019-11-01 14:50:12 -07:00
|
|
|
|
2018-10-20 07:36:39 +00:00
|
|
|
for (const RangeSpanList &List : Holder.getRangeLists())
|
2019-11-01 14:50:12 -07:00
|
|
|
emitRangeList(*this, Asm, List);
|
2018-10-20 07:36:39 +00:00
|
|
|
|
|
|
|
if (TableEnd)
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(TableEnd);
|
2018-10-20 07:36:39 +00:00
|
|
|
}
|
|
|
|
|
2018-07-26 22:48:52 +00:00
|
|
|
/// Emit address ranges into the .debug_ranges section or into the DWARF v5
|
|
|
|
/// .debug_rnglists section.
|
2009-11-21 02:48:08 +00:00
|
|
|
void DwarfDebug::emitDebugRanges() {
|
2018-10-20 07:36:39 +00:00
|
|
|
const auto &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
2018-08-01 19:38:20 +00:00
|
|
|
|
2019-11-01 14:50:12 -07:00
|
|
|
emitDebugRangesImpl(Holder,
|
|
|
|
getDwarfVersion() >= 5
|
|
|
|
? Asm->getObjFileLowering().getDwarfRnglistsSection()
|
|
|
|
: Asm->getObjFileLowering().getDwarfRangesSection());
|
2009-05-20 23:21:38 +00:00
|
|
|
}
|
|
|
|
|
2018-10-20 08:12:36 +00:00
|
|
|
void DwarfDebug::emitDebugRangesDWO() {
|
2019-11-01 14:50:12 -07:00
|
|
|
emitDebugRangesImpl(InfoHolder,
|
|
|
|
Asm->getObjFileLowering().getDwarfRnglistsDWOSection());
|
2018-10-20 08:12:36 +00:00
|
|
|
}
|
|
|
|
|
2020-04-03 12:44:09 +05:30
|
|
|
/// Emit the header of a DWARF 5 macro section.
|
|
|
|
static void emitMacroHeader(AsmPrinter *Asm, const DwarfDebug &DD,
|
|
|
|
const DwarfCompileUnit &CU) {
|
|
|
|
enum HeaderFlagMask {
|
|
|
|
#define HANDLE_MACRO_FLAG(ID, NAME) MACRO_FLAG_##NAME = ID,
|
|
|
|
#include "llvm/BinaryFormat/Dwarf.def"
|
|
|
|
};
|
|
|
|
uint8_t Flags = 0;
|
|
|
|
Asm->OutStreamer->AddComment("Macro information version");
|
|
|
|
Asm->emitInt16(5);
|
|
|
|
// We are setting Offset and line offset flags unconditionally here,
|
|
|
|
// since we're only supporting DWARF32 and line offset should be mostly
|
|
|
|
// present.
|
|
|
|
// FIXME: Add support for DWARF64.
|
|
|
|
Flags |= MACRO_FLAG_DEBUG_LINE_OFFSET;
|
|
|
|
Asm->OutStreamer->AddComment("Flags: 32 bit, debug_line_offset present");
|
|
|
|
Asm->emitInt8(Flags);
|
|
|
|
Asm->OutStreamer->AddComment("debug_line_offset");
|
|
|
|
Asm->OutStreamer->emitSymbolValue(CU.getLineTableStartSym(), /*Size=*/4);
|
|
|
|
}
|
|
|
|
|
2016-02-01 14:09:41 +00:00
|
|
|
void DwarfDebug::handleMacroNodes(DIMacroNodeArray Nodes, DwarfCompileUnit &U) {
|
2016-01-07 14:28:20 +00:00
|
|
|
for (auto *MN : Nodes) {
|
|
|
|
if (auto *M = dyn_cast<DIMacro>(MN))
|
2016-02-01 14:09:41 +00:00
|
|
|
emitMacro(*M);
|
2016-01-07 14:28:20 +00:00
|
|
|
else if (auto *F = dyn_cast<DIMacroFile>(MN))
|
2016-02-01 14:09:41 +00:00
|
|
|
emitMacroFile(*F, U);
|
2016-01-07 14:28:20 +00:00
|
|
|
else
|
|
|
|
llvm_unreachable("Unexpected DI type!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-02-01 14:09:41 +00:00
|
|
|
void DwarfDebug::emitMacro(DIMacro &M) {
|
2016-01-07 14:28:20 +00:00
|
|
|
StringRef Name = M.getName();
|
|
|
|
StringRef Value = M.getValue();
|
2020-04-03 12:44:09 +05:30
|
|
|
bool UseMacro = getDwarfVersion() >= 5;
|
|
|
|
|
|
|
|
if (UseMacro) {
|
|
|
|
unsigned Type = M.getMacinfoType() == dwarf::DW_MACINFO_define
|
2020-05-30 00:22:40 +05:30
|
|
|
? dwarf::DW_MACRO_define_strx
|
|
|
|
: dwarf::DW_MACRO_undef_strx;
|
2020-04-03 12:44:09 +05:30
|
|
|
Asm->OutStreamer->AddComment(dwarf::MacroString(Type));
|
|
|
|
Asm->emitULEB128(Type);
|
|
|
|
Asm->OutStreamer->AddComment("Line Number");
|
|
|
|
Asm->emitULEB128(M.getLine());
|
|
|
|
Asm->OutStreamer->AddComment("Macro String");
|
|
|
|
if (!Value.empty())
|
2020-05-30 00:22:40 +05:30
|
|
|
Asm->emitULEB128(this->InfoHolder.getStringPool()
|
|
|
|
.getIndexedEntry(*Asm, (Name + " " + Value).str())
|
|
|
|
.getIndex());
|
2020-04-03 12:44:09 +05:30
|
|
|
else
|
2020-05-30 00:22:40 +05:30
|
|
|
// DW_MACRO_undef_strx doesn't have a value, so just emit the macro
|
2020-04-03 12:44:09 +05:30
|
|
|
// string.
|
2020-05-30 00:22:40 +05:30
|
|
|
Asm->emitULEB128(this->InfoHolder.getStringPool()
|
|
|
|
.getIndexedEntry(*Asm, (Name).str())
|
|
|
|
.getIndex());
|
2020-04-03 12:44:09 +05:30
|
|
|
} else {
|
|
|
|
Asm->OutStreamer->AddComment(dwarf::MacinfoString(M.getMacinfoType()));
|
|
|
|
Asm->emitULEB128(M.getMacinfoType());
|
|
|
|
Asm->OutStreamer->AddComment("Line Number");
|
|
|
|
Asm->emitULEB128(M.getLine());
|
|
|
|
Asm->OutStreamer->AddComment("Macro String");
|
|
|
|
Asm->OutStreamer->emitBytes(Name);
|
|
|
|
if (!Value.empty()) {
|
|
|
|
// There should be one space between macro name and macro value.
|
|
|
|
Asm->emitInt8(' ');
|
|
|
|
Asm->OutStreamer->AddComment("Macro Value=");
|
|
|
|
Asm->OutStreamer->emitBytes(Value);
|
|
|
|
}
|
|
|
|
Asm->emitInt8('\0');
|
2016-01-07 14:28:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-03 12:44:09 +05:30
|
|
|
void DwarfDebug::emitMacroFileImpl(
|
|
|
|
DIMacroFile &F, DwarfCompileUnit &U, unsigned StartFile, unsigned EndFile,
|
|
|
|
StringRef (*MacroFormToString)(unsigned Form)) {
|
|
|
|
|
|
|
|
Asm->OutStreamer->AddComment(MacroFormToString(StartFile));
|
|
|
|
Asm->emitULEB128(StartFile);
|
|
|
|
Asm->OutStreamer->AddComment("Line Number");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(F.getLine());
|
2020-04-03 12:44:09 +05:30
|
|
|
Asm->OutStreamer->AddComment("File Number");
|
2020-02-13 13:26:21 -08:00
|
|
|
Asm->emitULEB128(U.getOrCreateSourceID(F.getFile()));
|
2016-02-01 14:09:41 +00:00
|
|
|
handleMacroNodes(F.getElements(), U);
|
2020-04-03 12:44:09 +05:30
|
|
|
Asm->OutStreamer->AddComment(MacroFormToString(EndFile));
|
|
|
|
Asm->emitULEB128(EndFile);
|
|
|
|
}
|
|
|
|
|
|
|
|
void DwarfDebug::emitMacroFile(DIMacroFile &F, DwarfCompileUnit &U) {
|
|
|
|
// DWARFv5 macro and DWARFv4 macinfo share some common encodings,
|
|
|
|
// so for readibility/uniformity, We are explicitly emitting those.
|
|
|
|
assert(F.getMacinfoType() == dwarf::DW_MACINFO_start_file);
|
|
|
|
bool UseMacro = getDwarfVersion() >= 5;
|
|
|
|
if (UseMacro)
|
|
|
|
emitMacroFileImpl(F, U, dwarf::DW_MACRO_start_file,
|
|
|
|
dwarf::DW_MACRO_end_file, dwarf::MacroString);
|
|
|
|
else
|
|
|
|
emitMacroFileImpl(F, U, dwarf::DW_MACINFO_start_file,
|
|
|
|
dwarf::DW_MACINFO_end_file, dwarf::MacinfoString);
|
2016-01-07 14:28:20 +00:00
|
|
|
}
|
|
|
|
|
2019-12-04 18:32:39 +05:30
|
|
|
void DwarfDebug::emitDebugMacinfoImpl(MCSection *Section) {
|
2016-01-07 14:28:20 +00:00
|
|
|
for (const auto &P : CUMap) {
|
|
|
|
auto &TheCU = *P.second;
|
|
|
|
auto *SkCU = TheCU.getSkeleton();
|
|
|
|
DwarfCompileUnit &U = SkCU ? *SkCU : TheCU;
|
|
|
|
auto *CUNode = cast<DICompileUnit>(P.first);
|
2018-02-22 16:20:30 +00:00
|
|
|
DIMacroNodeArray Macros = CUNode->getMacros();
|
2019-11-08 15:31:15 -08:00
|
|
|
if (Macros.empty())
|
|
|
|
continue;
|
2019-12-04 18:32:39 +05:30
|
|
|
Asm->OutStreamer->SwitchSection(Section);
|
2020-02-14 19:21:58 -08:00
|
|
|
Asm->OutStreamer->emitLabel(U.getMacroLabelBegin());
|
2020-04-03 12:44:09 +05:30
|
|
|
if (getDwarfVersion() >= 5)
|
|
|
|
emitMacroHeader(Asm, *this, U);
|
2019-11-08 15:31:15 -08:00
|
|
|
handleMacroNodes(Macros, U);
|
|
|
|
Asm->OutStreamer->AddComment("End Of Macro List Mark");
|
|
|
|
Asm->emitInt8(0);
|
2016-01-07 14:28:20 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-04-03 12:44:09 +05:30
|
|
|
/// Emit macros into a debug macinfo/macro section.
|
2019-12-04 18:32:39 +05:30
|
|
|
void DwarfDebug::emitDebugMacinfo() {
|
2020-04-03 12:44:09 +05:30
|
|
|
auto &ObjLower = Asm->getObjFileLowering();
|
|
|
|
emitDebugMacinfoImpl(getDwarfVersion() >= 5
|
|
|
|
? ObjLower.getDwarfMacroSection()
|
|
|
|
: ObjLower.getDwarfMacinfoSection());
|
2019-12-04 18:32:39 +05:30
|
|
|
}
|
|
|
|
|
2019-11-11 12:53:19 +05:30
|
|
|
void DwarfDebug::emitDebugMacinfoDWO() {
|
2020-05-30 11:11:09 +05:30
|
|
|
auto &ObjLower = Asm->getObjFileLowering();
|
|
|
|
emitDebugMacinfoImpl(getDwarfVersion() >= 5
|
|
|
|
? ObjLower.getDwarfMacroDWOSection()
|
|
|
|
: ObjLower.getDwarfMacinfoDWOSection());
|
2019-11-11 12:53:19 +05:30
|
|
|
}
|
|
|
|
|
2012-12-11 19:42:09 +00:00
|
|
|
// DWARF5 Experimental Separate Dwarf emitters.
|
2012-11-30 23:59:06 +00:00
|
|
|
|
2014-04-25 18:26:14 +00:00
|
|
|
void DwarfDebug::initSkeletonUnit(const DwarfUnit &U, DIE &Die,
|
2016-02-11 19:57:46 +00:00
|
|
|
std::unique_ptr<DwarfCompileUnit> NewU) {
|
2014-01-09 04:28:46 +00:00
|
|
|
|
|
|
|
if (!CompilationDir.empty())
|
2014-11-02 08:51:37 +00:00
|
|
|
NewU->addString(Die, dwarf::DW_AT_comp_dir, CompilationDir);
|
2014-04-22 22:39:41 +00:00
|
|
|
addGnuPubAttributes(*NewU, Die);
|
2014-01-09 04:28:46 +00:00
|
|
|
|
2014-04-22 22:39:41 +00:00
|
|
|
SkeletonHolder.addUnit(std::move(NewU));
|
2014-01-09 04:28:46 +00:00
|
|
|
}
|
|
|
|
|
2014-04-22 22:39:41 +00:00
|
|
|
DwarfCompileUnit &DwarfDebug::constructSkeletonCU(const DwarfCompileUnit &CU) {
|
2012-11-30 23:59:06 +00:00
|
|
|
|
2019-08-15 15:54:37 +00:00
|
|
|
auto OwnedUnit = std::make_unique<DwarfCompileUnit>(
|
2019-11-30 23:48:32 +03:00
|
|
|
CU.getUniqueID(), CU.getCUNode(), Asm, this, &SkeletonHolder,
|
|
|
|
UnitKind::Skeleton);
|
2014-04-22 22:39:41 +00:00
|
|
|
DwarfCompileUnit &NewCU = *OwnedUnit;
|
2016-12-01 18:56:29 +00:00
|
|
|
NewCU.setSection(Asm->getObjFileLowering().getDwarfInfoSection());
|
2013-01-17 03:00:04 +00:00
|
|
|
|
2015-03-10 16:58:10 +00:00
|
|
|
NewCU.initStmtList();
|
2012-11-30 23:59:06 +00:00
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
if (useSegmentedStringOffsetsTable())
|
|
|
|
NewCU.addStringOffsetsStart();
|
|
|
|
|
2014-04-28 21:04:29 +00:00
|
|
|
initSkeletonUnit(CU, NewCU.getUnitDie(), std::move(OwnedUnit));
|
2012-12-10 23:34:43 +00:00
|
|
|
|
2012-11-30 23:59:06 +00:00
|
|
|
return NewCU;
|
|
|
|
}
|
|
|
|
|
2012-12-11 19:42:09 +00:00
|
|
|
// Emit the .debug_info.dwo section for separated dwarf. This contains the
|
|
|
|
// compile units that would normally be in debug_info.
|
2012-11-30 23:59:06 +00:00
|
|
|
void DwarfDebug::emitDebugInfoDWO() {
|
2012-12-10 19:51:21 +00:00
|
|
|
assert(useSplitDwarf() && "No split dwarf debug info?");
|
2015-03-10 16:58:10 +00:00
|
|
|
// Don't emit relocations into the dwo file.
|
|
|
|
InfoHolder.emitUnits(/* UseOffsets */ true);
|
2012-12-19 22:02:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Emit the .debug_abbrev.dwo section for separated dwarf. This contains the
|
|
|
|
// abbreviations for the .debug_info.dwo section.
|
|
|
|
void DwarfDebug::emitDebugAbbrevDWO() {
|
|
|
|
assert(useSplitDwarf() && "No split dwarf?");
|
2013-12-05 07:43:55 +00:00
|
|
|
InfoHolder.emitAbbrevs(Asm->getObjFileLowering().getDwarfAbbrevDWOSection());
|
2012-11-30 23:59:06 +00:00
|
|
|
}
|
2012-12-27 02:14:01 +00:00
|
|
|
|
2014-03-18 01:17:26 +00:00
|
|
|
void DwarfDebug::emitDebugLineDWO() {
|
|
|
|
assert(useSplitDwarf() && "No split dwarf?");
|
2018-03-27 21:28:59 +00:00
|
|
|
SplitTypeUnitFileTable.Emit(
|
|
|
|
*Asm->OutStreamer, MCDwarfLineTableParams(),
|
2014-03-18 01:17:26 +00:00
|
|
|
Asm->getObjFileLowering().getDwarfLineDWOSection());
|
|
|
|
}
|
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
void DwarfDebug::emitStringOffsetsTableHeaderDWO() {
|
|
|
|
assert(useSplitDwarf() && "No split dwarf?");
|
2018-07-26 14:36:07 +00:00
|
|
|
InfoHolder.getStringPool().emitStringOffsetsTableHeader(
|
|
|
|
*Asm, Asm->getObjFileLowering().getDwarfStrOffDWOSection(),
|
|
|
|
InfoHolder.getStringOffsetsStartSym());
|
2018-01-26 18:52:58 +00:00
|
|
|
}
|
|
|
|
|
2012-12-27 02:14:01 +00:00
|
|
|
// Emit the .debug_str.dwo section for separated dwarf. This contains the
|
|
|
|
// string section and is identical in format to traditional .debug_str
|
|
|
|
// sections.
|
|
|
|
void DwarfDebug::emitDebugStrDWO() {
|
2018-01-26 18:52:58 +00:00
|
|
|
if (useSegmentedStringOffsetsTable())
|
|
|
|
emitStringOffsetsTableHeaderDWO();
|
2012-12-27 02:14:01 +00:00
|
|
|
assert(useSplitDwarf() && "No split dwarf?");
|
2015-05-21 19:20:38 +00:00
|
|
|
MCSection *OffSec = Asm->getObjFileLowering().getDwarfStrOffDWOSection();
|
2013-01-07 19:32:41 +00:00
|
|
|
InfoHolder.emitStrings(Asm->getObjFileLowering().getDwarfStrDWOSection(),
|
2018-01-26 18:52:58 +00:00
|
|
|
OffSec, /* UseRelativeOffsets = */ false);
|
2012-12-27 02:14:01 +00:00
|
|
|
}
|
2013-11-19 23:08:21 +00:00
|
|
|
|
2018-10-20 06:02:15 +00:00
|
|
|
// Emit address pool.
|
2018-08-01 05:48:06 +00:00
|
|
|
void DwarfDebug::emitDebugAddr() {
|
|
|
|
AddrPool.emit(*Asm, Asm->getObjFileLowering().getDwarfAddrSection());
|
|
|
|
}
|
|
|
|
|
2014-03-19 00:11:28 +00:00
|
|
|
MCDwarfDwoLineTable *DwarfDebug::getDwoLineTable(const DwarfCompileUnit &CU) {
|
|
|
|
if (!useSplitDwarf())
|
|
|
|
return nullptr;
|
2018-03-29 17:16:41 +00:00
|
|
|
const DICompileUnit *DIUnit = CU.getCUNode();
|
|
|
|
SplitTypeUnitFileTable.maybeSetRootFile(
|
|
|
|
DIUnit->getDirectory(), DIUnit->getFilename(),
|
|
|
|
CU.getMD5AsBytes(DIUnit->getFile()), DIUnit->getSource());
|
2014-03-19 00:11:28 +00:00
|
|
|
return &SplitTypeUnitFileTable;
|
|
|
|
}
|
|
|
|
|
2015-07-15 17:01:41 +00:00
|
|
|
uint64_t DwarfDebug::makeTypeSignature(StringRef Identifier) {
|
2014-04-26 16:26:41 +00:00
|
|
|
MD5 Hash;
|
|
|
|
Hash.update(Identifier);
|
|
|
|
// ... take the least significant 8 bytes and return those. Our MD5
|
2017-03-20 23:33:18 +00:00
|
|
|
// implementation always returns its results in little endian, so we actually
|
|
|
|
// need the "high" word.
|
2014-04-26 16:26:41 +00:00
|
|
|
MD5::MD5Result Result;
|
|
|
|
Hash.final(Result);
|
2017-03-20 23:33:18 +00:00
|
|
|
return Result.high();
|
2014-04-26 16:26:41 +00:00
|
|
|
}
|
|
|
|
|
2014-02-12 00:31:30 +00:00
|
|
|
void DwarfDebug::addDwarfTypeUnitType(DwarfCompileUnit &CU,
|
2014-04-25 18:26:14 +00:00
|
|
|
StringRef Identifier, DIE &RefDie,
|
2015-04-29 16:38:44 +00:00
|
|
|
const DICompositeType *CTy) {
|
2014-04-26 17:27:38 +00:00
|
|
|
// Fast path if we're building some type units and one has already used the
|
|
|
|
// address pool we know we're going to throw away all this work anyway, so
|
|
|
|
// don't bother building dependent types.
|
|
|
|
if (!TypeUnitsUnderConstruction.empty() && AddrPool.hasBeenUsed())
|
|
|
|
return;
|
|
|
|
|
2016-02-11 19:57:46 +00:00
|
|
|
auto Ins = TypeSignatures.insert(std::make_pair(CTy, 0));
|
|
|
|
if (!Ins.second) {
|
|
|
|
CU.addDIETypeSignature(RefDie, Ins.first->second);
|
2014-01-20 08:07:07 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-26 17:27:38 +00:00
|
|
|
bool TopLevelType = TypeUnitsUnderConstruction.empty();
|
|
|
|
AddrPool.resetUsedFlag();
|
|
|
|
|
2019-08-15 15:54:37 +00:00
|
|
|
auto OwnedUnit = std::make_unique<DwarfTypeUnit>(CU, Asm, this, &InfoHolder,
|
2017-08-17 21:26:39 +00:00
|
|
|
getDwoLineTable(CU));
|
2014-04-22 22:39:41 +00:00
|
|
|
DwarfTypeUnit &NewTU = *OwnedUnit;
|
2014-04-28 21:04:29 +00:00
|
|
|
DIE &UnitDie = NewTU.getUnitDie();
|
2016-08-11 21:15:00 +00:00
|
|
|
TypeUnitsUnderConstruction.emplace_back(std::move(OwnedUnit), CTy);
|
2014-04-22 22:39:41 +00:00
|
|
|
|
2014-04-28 21:04:29 +00:00
|
|
|
NewTU.addUInt(UnitDie, dwarf::DW_AT_language, dwarf::DW_FORM_data2,
|
2014-04-22 23:09:36 +00:00
|
|
|
CU.getLanguage());
|
2014-01-20 08:07:07 +00:00
|
|
|
|
2014-04-26 16:26:41 +00:00
|
|
|
uint64_t Signature = makeTypeSignature(Identifier);
|
2014-04-22 22:39:41 +00:00
|
|
|
NewTU.setTypeSignature(Signature);
|
2016-02-11 19:57:46 +00:00
|
|
|
Ins.first->second = Signature;
|
2014-04-26 16:26:41 +00:00
|
|
|
|
2018-11-12 16:55:11 +00:00
|
|
|
if (useSplitDwarf()) {
|
|
|
|
MCSection *Section =
|
|
|
|
getDwarfVersion() <= 4
|
|
|
|
? Asm->getObjFileLowering().getDwarfTypesDWOSection()
|
|
|
|
: Asm->getObjFileLowering().getDwarfInfoDWOSection();
|
|
|
|
NewTU.setSection(Section);
|
|
|
|
} else {
|
2018-11-09 19:06:09 +00:00
|
|
|
MCSection *Section =
|
|
|
|
getDwarfVersion() <= 4
|
|
|
|
? Asm->getObjFileLowering().getDwarfTypesSection(Signature)
|
|
|
|
: Asm->getObjFileLowering().getDwarfInfoSection(Signature);
|
|
|
|
NewTU.setSection(Section);
|
2018-03-27 21:28:59 +00:00
|
|
|
// Non-split type units reuse the compile unit's line table.
|
|
|
|
CU.applyStmtList(UnitDie);
|
2014-07-25 17:11:58 +00:00
|
|
|
}
|
2014-01-20 08:07:07 +00:00
|
|
|
|
2018-01-26 18:52:58 +00:00
|
|
|
// Add DW_AT_str_offsets_base to the type unit DIE, but not for split type
|
|
|
|
// units.
|
|
|
|
if (useSegmentedStringOffsetsTable() && !useSplitDwarf())
|
|
|
|
NewTU.addStringOffsetsStart();
|
|
|
|
|
2014-04-26 16:26:41 +00:00
|
|
|
NewTU.setType(NewTU.createTypeDIE(CTy));
|
|
|
|
|
2014-04-26 17:27:38 +00:00
|
|
|
if (TopLevelType) {
|
|
|
|
auto TypeUnitsToAdd = std::move(TypeUnitsUnderConstruction);
|
|
|
|
TypeUnitsUnderConstruction.clear();
|
|
|
|
|
|
|
|
// Types referencing entries in the address table cannot be placed in type
|
|
|
|
// units.
|
|
|
|
if (AddrPool.hasBeenUsed()) {
|
|
|
|
|
|
|
|
// Remove all the types built while building this type.
|
|
|
|
// This is pessimistic as some of these types might not be dependent on
|
|
|
|
// the type that used an address.
|
|
|
|
for (const auto &TU : TypeUnitsToAdd)
|
2016-02-11 19:57:46 +00:00
|
|
|
TypeSignatures.erase(TU.second);
|
2014-04-26 17:27:38 +00:00
|
|
|
|
|
|
|
// Construct this type in the CU directly.
|
|
|
|
// This is inefficient because all the dependent types will be rebuilt
|
|
|
|
// from scratch, including building them in type units, discovering that
|
|
|
|
// they depend on addresses, throwing them out and rebuilding them.
|
2015-04-29 16:38:44 +00:00
|
|
|
CU.constructTypeDIE(RefDie, cast<DICompositeType>(CTy));
|
2014-04-26 17:27:38 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the type wasn't dependent on fission addresses, finish adding the type
|
|
|
|
// and all its dependent types.
|
2016-02-11 19:57:46 +00:00
|
|
|
for (auto &TU : TypeUnitsToAdd) {
|
|
|
|
InfoHolder.computeSizeAndOffsetsForUnit(TU.first.get());
|
|
|
|
InfoHolder.emitUnit(TU.first.get(), useSplitDwarf());
|
|
|
|
}
|
2014-04-26 17:27:38 +00:00
|
|
|
}
|
2016-02-11 19:57:46 +00:00
|
|
|
CU.addDIETypeSignature(RefDie, Signature);
|
2013-11-19 23:08:21 +00:00
|
|
|
}
|
2014-03-07 18:49:45 +00:00
|
|
|
|
2019-04-24 18:09:44 +00:00
|
|
|
DwarfDebug::NonTypeUnitContext::NonTypeUnitContext(DwarfDebug *DD)
|
|
|
|
: DD(DD),
|
|
|
|
TypeUnitsUnderConstruction(std::move(DD->TypeUnitsUnderConstruction)) {
|
|
|
|
DD->TypeUnitsUnderConstruction.clear();
|
|
|
|
assert(TypeUnitsUnderConstruction.empty() || !DD->AddrPool.hasBeenUsed());
|
|
|
|
}
|
|
|
|
|
|
|
|
DwarfDebug::NonTypeUnitContext::~NonTypeUnitContext() {
|
|
|
|
DD->TypeUnitsUnderConstruction = std::move(TypeUnitsUnderConstruction);
|
|
|
|
DD->AddrPool.resetUsedFlag();
|
|
|
|
}
|
|
|
|
|
|
|
|
DwarfDebug::NonTypeUnitContext DwarfDebug::enterNonTypeUnitContext() {
|
|
|
|
return NonTypeUnitContext(this);
|
|
|
|
}
|
|
|
|
|
2018-07-20 15:24:13 +00:00
|
|
|
// Add the Name along with its companion DIE to the appropriate accelerator
|
|
|
|
// table (for AccelTableKind::Dwarf it's always AccelDebugNames, for
|
|
|
|
// AccelTableKind::Apple, we use the table we got as an argument). If
|
|
|
|
// accelerator tables are disabled, this function does nothing.
|
|
|
|
template <typename DataT>
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addAccelNameImpl(const DICompileUnit &CU,
|
|
|
|
AccelTable<DataT> &AppleAccel, StringRef Name,
|
2018-07-20 15:24:13 +00:00
|
|
|
const DIE &Die) {
|
|
|
|
if (getAccelTableKind() == AccelTableKind::None)
|
|
|
|
return;
|
2018-04-18 12:11:59 +00:00
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
if (getAccelTableKind() != AccelTableKind::Apple &&
|
2019-04-23 19:00:45 +00:00
|
|
|
CU.getNameTableKind() != DICompileUnit::DebugNameTableKind::Default)
|
2018-08-16 21:29:55 +00:00
|
|
|
return;
|
|
|
|
|
2018-04-18 12:11:59 +00:00
|
|
|
DwarfFile &Holder = useSplitDwarf() ? SkeletonHolder : InfoHolder;
|
[DebugInfo] Reduce debug_str_offsets section size
Summary:
The accelerator tables use the debug_str section to store their strings.
However, they do not support the indirect method of access that is
available for the debug_info section (DW_FORM_strx et al.).
Currently our code is assuming that all strings can/will be referenced
indirectly, and puts all of them into the debug_str_offsets section.
This is generally true for regular (unsplit) dwarf, but in the DWO case,
most of the strings in the debug_str section will only be used from the
accelerator tables. Therefore the contents of the debug_str_offsets
section will be largely unused and bloating the main executable.
This patch rectifies this by teaching the DwarfStringPool to
differentiate between strings accessed directly and indirectly. When a
user inserts a string into the pool it has to declare whether that
string will be referenced directly or not. If at least one user requsts
indirect access, that string will be assigned an index ID and put into
debug_str_offsets table. Otherwise, the offset table is skipped.
This approach reduces the overall binary size (when compiled with
-gdwarf-5 -gsplit-dwarf) in my tests by about 2% (debug_str_offsets is
shrunk by 99%).
Reviewers: probinson, dblaikie, JDevlieghere
Subscribers: aprantl, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D49493
llvm-svn: 339122
2018-08-07 09:54:52 +00:00
|
|
|
DwarfStringPoolEntryRef Ref = Holder.getStringPool().getEntry(*Asm, Name);
|
2018-04-18 12:11:59 +00:00
|
|
|
|
2018-04-04 14:42:14 +00:00
|
|
|
switch (getAccelTableKind()) {
|
|
|
|
case AccelTableKind::Apple:
|
2018-07-20 15:24:13 +00:00
|
|
|
AppleAccel.addName(Ref, Die);
|
2018-04-04 14:42:14 +00:00
|
|
|
break;
|
|
|
|
case AccelTableKind::Dwarf:
|
2018-07-20 15:24:13 +00:00
|
|
|
AccelDebugNames.addName(Ref, Die);
|
2018-04-04 14:42:14 +00:00
|
|
|
break;
|
|
|
|
case AccelTableKind::Default:
|
|
|
|
llvm_unreachable("Default should have already been resolved.");
|
2018-07-20 15:24:13 +00:00
|
|
|
case AccelTableKind::None:
|
|
|
|
llvm_unreachable("None handled above");
|
2018-04-04 14:42:14 +00:00
|
|
|
}
|
2014-04-23 23:37:35 +00:00
|
|
|
}
|
2014-04-24 00:53:32 +00:00
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addAccelName(const DICompileUnit &CU, StringRef Name,
|
|
|
|
const DIE &Die) {
|
|
|
|
addAccelNameImpl(CU, AccelNames, Name, Die);
|
2018-07-20 15:24:13 +00:00
|
|
|
}
|
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addAccelObjC(const DICompileUnit &CU, StringRef Name,
|
|
|
|
const DIE &Die) {
|
2018-07-20 15:24:13 +00:00
|
|
|
// ObjC names go only into the Apple accelerator tables.
|
|
|
|
if (getAccelTableKind() == AccelTableKind::Apple)
|
2018-08-16 21:29:55 +00:00
|
|
|
addAccelNameImpl(CU, AccelObjC, Name, Die);
|
2014-04-24 00:53:32 +00:00
|
|
|
}
|
2014-04-24 01:02:42 +00:00
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addAccelNamespace(const DICompileUnit &CU, StringRef Name,
|
|
|
|
const DIE &Die) {
|
|
|
|
addAccelNameImpl(CU, AccelNamespace, Name, Die);
|
2014-04-24 01:02:42 +00:00
|
|
|
}
|
2014-04-24 01:23:49 +00:00
|
|
|
|
2018-08-16 21:29:55 +00:00
|
|
|
void DwarfDebug::addAccelType(const DICompileUnit &CU, StringRef Name,
|
|
|
|
const DIE &Die, char Flags) {
|
|
|
|
addAccelNameImpl(CU, AccelTypes, Name, Die);
|
2014-04-24 01:23:49 +00:00
|
|
|
}
|
2016-11-23 23:30:37 +00:00
|
|
|
|
|
|
|
uint16_t DwarfDebug::getDwarfVersion() const {
|
|
|
|
return Asm->OutStreamer->getContext().getDwarfVersion();
|
|
|
|
}
|
2018-10-24 23:36:29 +00:00
|
|
|
|
|
|
|
const MCSymbol *DwarfDebug::getSectionLabel(const MCSection *S) {
|
|
|
|
return SectionLabels.find(S)->second;
|
|
|
|
}
|
2020-01-17 18:12:34 -08:00
|
|
|
void DwarfDebug::insertSectionLabel(const MCSymbol *S) {
|
2020-05-17 12:17:31 -07:00
|
|
|
if (SectionLabels.insert(std::make_pair(&S->getSection(), S)).second)
|
|
|
|
if (useSplitDwarf() || getDwarfVersion() >= 5)
|
|
|
|
AddrPool.getIndex(S);
|
2020-01-17 18:12:34 -08:00
|
|
|
}
|