2018-04-10 02:09:15 +02:00
|
|
|
//===- RecordName.cpp ----------------------------------------- *- C++ --*-===//
|
|
|
|
//
|
2019-01-19 09:50:56 +01: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
|
2018-04-10 02:09:15 +02:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/DebugInfo/CodeView/RecordName.h"
|
|
|
|
|
|
|
|
#include "llvm/ADT/SmallString.h"
|
Re-land "[PDB] Merge types in parallel when using ghashing"
Stored Error objects have to be checked, even if they are success
values.
This reverts commit 8d250ac3cd48d0f17f9314685a85e77895c05351.
Relands commit 49b3459930655d879b2dc190ff8fe11c38a8be5f..
Original commit message:
-----------------------------------------
This makes type merging much faster (-24% on chrome.dll) when multiple
threads are available, but it slightly increases the time to link (+10%)
when /threads:1 is passed. With only one more thread, the new type
merging is faster (-11%). The output PDB should be identical to what it
was before this change.
To give an idea, here is the /time output placed side by side:
BEFORE | AFTER
Input File Reading: 956 ms | 968 ms
Code Layout: 258 ms | 190 ms
Commit Output File: 6 ms | 7 ms
PDB Emission (Cumulative): 6691 ms | 4253 ms
Add Objects: 4341 ms | 2927 ms
Type Merging: 2814 ms | 1269 ms -55%!
Symbol Merging: 1509 ms | 1645 ms
Publics Stream Layout: 111 ms | 112 ms
TPI Stream Layout: 764 ms | 26 ms trivial
Commit to Disk: 1322 ms | 1036 ms -300ms
----------------------------------------- --------
Total Link Time: 8416 ms 5882 ms -30% overall
The main source of the additional overhead in the single-threaded case
is the need to iterate all .debug$T sections up front to check which
type records should go in the IPI stream. See fillIsItemIndexFromDebugT.
With changes to the .debug$H section, we could pre-calculate this info
and eliminate the need to do this walk up front. That should restore
single-threaded performance back to what it was before this change.
This change will cause LLD to be much more parallel than it used to, and
for users who do multiple links in parallel, it could regress
performance. However, when the user is only doing one link, it's a huge
improvement. In the future, we can use NT worker threads to avoid
oversaturating the machine with work, but for now, this is such an
improvement for the single-link use case that I think we should land
this as is.
Algorithm
----------
Before this change, we essentially used a
DenseMap<GloballyHashedType, TypeIndex> to check if a type has already
been seen, and if it hasn't been seen, insert it now and use the next
available type index for it in the destination type stream. DenseMap
does not support concurrent insertion, and even if it did, the linker
must be deterministic: it cannot produce different PDBs by using
different numbers of threads. The output type stream must be in the same
order regardless of the order of hash table insertions.
In order to create a hash table that supports concurrent insertion, the
table cells must be small enough that they can be updated atomically.
The algorithm I used for updating the table using linear probing is
described in this paper, "Concurrent Hash Tables: Fast and General(?)!":
https://dl.acm.org/doi/10.1145/3309206
The GHashCell in this change is essentially a pair of 32-bit integer
indices: <sourceIndex, typeIndex>. The sourceIndex is the index of the
TpiSource object, and it represents an input type stream. The typeIndex
is the index of the type in the stream. Together, we have something like
a ragged 2D array of ghashes, which can be looked up as:
tpiSources[tpiSrcIndex]->ghashes[typeIndex]
By using these side tables, we can omit the key data from the hash
table, and keep the table cell small. There is a cost to this: resolving
hash table collisions requires many more loads than simply looking at
the key in the same cache line as the insertion position. However, most
supported platforms should have a 64-bit CAS operation to update the
cell atomically.
To make the result of concurrent insertion deterministic, the cell
payloads must have a priority function. Defining one is pretty
straightforward: compare the two 32-bit numbers as a combined 64-bit
number. This means that types coming from inputs earlier on the command
line have a higher priority and are more likely to appear earlier in the
final PDB type stream than types from an input appearing later on the
link line.
After table insertion, the non-empty cells in the table can be copied
out of the main table and sorted by priority to determine the ordering
of the final type index stream. At this point, item and type records
must be separated, either by sorting or by splitting into two arrays,
and I chose sorting. This is why the GHashCell must contain the isItem
bit.
Once the final PDB TPI stream ordering is known, we need to compute a
mapping from source type index to PDB type index. To avoid starting over
from scratch and looking up every type again by its ghash, we save the
insertion position of every hash table insertion during the first
insertion phase. Because the table does not support rehashing, the
insertion position is stable. Using the array of insertion positions
indexed by source type index, we can replace the source type indices in
the ghash table cells with the PDB type indices.
Once the table cells have been updated to contain PDB type indices, the
mapping for each type source can be computed in parallel. Simply iterate
the list of cell positions and replace them with the PDB type index,
since the insertion positions are no longer needed.
Once we have a source to destination type index mapping for every type
source, there are no more data dependencies. We know which type records
are "unique" (not duplicates), and what their final type indices will
be. We can do the remapping in parallel, and accumulate type sizes and
type hashes in parallel by type source.
Lastly, TPI stream layout must be done serially. Accumulate all the type
records, sizes, and hashes, and add them to the PDB.
Differential Revision: https://reviews.llvm.org/D87805
2020-09-30 23:55:51 +02:00
|
|
|
#include "llvm/ADT/StringExtras.h"
|
2018-04-10 02:09:15 +02:00
|
|
|
#include "llvm/DebugInfo/CodeView/CVSymbolVisitor.h"
|
|
|
|
#include "llvm/DebugInfo/CodeView/CVTypeVisitor.h"
|
|
|
|
#include "llvm/DebugInfo/CodeView/SymbolRecordMapping.h"
|
|
|
|
#include "llvm/DebugInfo/CodeView/TypeVisitorCallbacks.h"
|
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
using namespace llvm::codeview;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
class TypeNameComputer : public TypeVisitorCallbacks {
|
|
|
|
/// The type collection. Used to calculate names of nested types.
|
|
|
|
TypeCollection &Types;
|
|
|
|
TypeIndex CurrentTypeIndex = TypeIndex::None();
|
|
|
|
|
|
|
|
/// Name of the current type. Only valid before visitTypeEnd.
|
|
|
|
SmallString<256> Name;
|
|
|
|
|
|
|
|
public:
|
|
|
|
explicit TypeNameComputer(TypeCollection &Types) : Types(Types) {}
|
|
|
|
|
|
|
|
StringRef name() const { return Name; }
|
|
|
|
|
|
|
|
/// Paired begin/end actions for all types. Receives all record data,
|
|
|
|
/// including the fixed-length record prefix.
|
|
|
|
Error visitTypeBegin(CVType &Record) override;
|
|
|
|
Error visitTypeBegin(CVType &Record, TypeIndex Index) override;
|
|
|
|
Error visitTypeEnd(CVType &Record) override;
|
|
|
|
|
|
|
|
#define TYPE_RECORD(EnumName, EnumVal, Name) \
|
|
|
|
Error visitKnownRecord(CVType &CVR, Name##Record &Record) override;
|
|
|
|
#define TYPE_RECORD_ALIAS(EnumName, EnumVal, Name, AliasName)
|
|
|
|
#define MEMBER_RECORD(EnumName, EnumVal, Name)
|
|
|
|
#include "llvm/DebugInfo/CodeView/CodeViewTypes.def"
|
|
|
|
};
|
|
|
|
} // namespace
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitTypeBegin(CVType &Record) {
|
|
|
|
llvm_unreachable("Must call visitTypeBegin with a TypeIndex!");
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitTypeBegin(CVType &Record, TypeIndex Index) {
|
|
|
|
// Reset Name to the empty string. If the visitor sets it, we know it.
|
|
|
|
Name = "";
|
|
|
|
CurrentTypeIndex = Index;
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitTypeEnd(CVType &CVR) { return Error::success(); }
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
FieldListRecord &FieldList) {
|
|
|
|
Name = "<field list>";
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVRecord<TypeLeafKind> &CVR,
|
|
|
|
StringIdRecord &String) {
|
|
|
|
Name = String.getString();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, ArgListRecord &Args) {
|
|
|
|
auto Indices = Args.getIndices();
|
|
|
|
uint32_t Size = Indices.size();
|
|
|
|
Name = "(";
|
|
|
|
for (uint32_t I = 0; I < Size; ++I) {
|
Re-land "[PDB] Merge types in parallel when using ghashing"
Stored Error objects have to be checked, even if they are success
values.
This reverts commit 8d250ac3cd48d0f17f9314685a85e77895c05351.
Relands commit 49b3459930655d879b2dc190ff8fe11c38a8be5f..
Original commit message:
-----------------------------------------
This makes type merging much faster (-24% on chrome.dll) when multiple
threads are available, but it slightly increases the time to link (+10%)
when /threads:1 is passed. With only one more thread, the new type
merging is faster (-11%). The output PDB should be identical to what it
was before this change.
To give an idea, here is the /time output placed side by side:
BEFORE | AFTER
Input File Reading: 956 ms | 968 ms
Code Layout: 258 ms | 190 ms
Commit Output File: 6 ms | 7 ms
PDB Emission (Cumulative): 6691 ms | 4253 ms
Add Objects: 4341 ms | 2927 ms
Type Merging: 2814 ms | 1269 ms -55%!
Symbol Merging: 1509 ms | 1645 ms
Publics Stream Layout: 111 ms | 112 ms
TPI Stream Layout: 764 ms | 26 ms trivial
Commit to Disk: 1322 ms | 1036 ms -300ms
----------------------------------------- --------
Total Link Time: 8416 ms 5882 ms -30% overall
The main source of the additional overhead in the single-threaded case
is the need to iterate all .debug$T sections up front to check which
type records should go in the IPI stream. See fillIsItemIndexFromDebugT.
With changes to the .debug$H section, we could pre-calculate this info
and eliminate the need to do this walk up front. That should restore
single-threaded performance back to what it was before this change.
This change will cause LLD to be much more parallel than it used to, and
for users who do multiple links in parallel, it could regress
performance. However, when the user is only doing one link, it's a huge
improvement. In the future, we can use NT worker threads to avoid
oversaturating the machine with work, but for now, this is such an
improvement for the single-link use case that I think we should land
this as is.
Algorithm
----------
Before this change, we essentially used a
DenseMap<GloballyHashedType, TypeIndex> to check if a type has already
been seen, and if it hasn't been seen, insert it now and use the next
available type index for it in the destination type stream. DenseMap
does not support concurrent insertion, and even if it did, the linker
must be deterministic: it cannot produce different PDBs by using
different numbers of threads. The output type stream must be in the same
order regardless of the order of hash table insertions.
In order to create a hash table that supports concurrent insertion, the
table cells must be small enough that they can be updated atomically.
The algorithm I used for updating the table using linear probing is
described in this paper, "Concurrent Hash Tables: Fast and General(?)!":
https://dl.acm.org/doi/10.1145/3309206
The GHashCell in this change is essentially a pair of 32-bit integer
indices: <sourceIndex, typeIndex>. The sourceIndex is the index of the
TpiSource object, and it represents an input type stream. The typeIndex
is the index of the type in the stream. Together, we have something like
a ragged 2D array of ghashes, which can be looked up as:
tpiSources[tpiSrcIndex]->ghashes[typeIndex]
By using these side tables, we can omit the key data from the hash
table, and keep the table cell small. There is a cost to this: resolving
hash table collisions requires many more loads than simply looking at
the key in the same cache line as the insertion position. However, most
supported platforms should have a 64-bit CAS operation to update the
cell atomically.
To make the result of concurrent insertion deterministic, the cell
payloads must have a priority function. Defining one is pretty
straightforward: compare the two 32-bit numbers as a combined 64-bit
number. This means that types coming from inputs earlier on the command
line have a higher priority and are more likely to appear earlier in the
final PDB type stream than types from an input appearing later on the
link line.
After table insertion, the non-empty cells in the table can be copied
out of the main table and sorted by priority to determine the ordering
of the final type index stream. At this point, item and type records
must be separated, either by sorting or by splitting into two arrays,
and I chose sorting. This is why the GHashCell must contain the isItem
bit.
Once the final PDB TPI stream ordering is known, we need to compute a
mapping from source type index to PDB type index. To avoid starting over
from scratch and looking up every type again by its ghash, we save the
insertion position of every hash table insertion during the first
insertion phase. Because the table does not support rehashing, the
insertion position is stable. Using the array of insertion positions
indexed by source type index, we can replace the source type indices in
the ghash table cells with the PDB type indices.
Once the table cells have been updated to contain PDB type indices, the
mapping for each type source can be computed in parallel. Simply iterate
the list of cell positions and replace them with the PDB type index,
since the insertion positions are no longer needed.
Once we have a source to destination type index mapping for every type
source, there are no more data dependencies. We know which type records
are "unique" (not duplicates), and what their final type indices will
be. We can do the remapping in parallel, and accumulate type sizes and
type hashes in parallel by type source.
Lastly, TPI stream layout must be done serially. Accumulate all the type
records, sizes, and hashes, and add them to the PDB.
Differential Revision: https://reviews.llvm.org/D87805
2020-09-30 23:55:51 +02:00
|
|
|
if (Indices[I] < CurrentTypeIndex)
|
|
|
|
Name.append(Types.getTypeName(Indices[I]));
|
|
|
|
else
|
|
|
|
Name.append("<unknown 0x" + utohexstr(Indices[I].getIndex()) + ">");
|
2018-04-10 02:09:15 +02:00
|
|
|
if (I + 1 != Size)
|
|
|
|
Name.append(", ");
|
|
|
|
}
|
|
|
|
Name.push_back(')');
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
StringListRecord &Strings) {
|
|
|
|
auto Indices = Strings.getIndices();
|
|
|
|
uint32_t Size = Indices.size();
|
|
|
|
Name = "\"";
|
|
|
|
for (uint32_t I = 0; I < Size; ++I) {
|
|
|
|
Name.append(Types.getTypeName(Indices[I]));
|
|
|
|
if (I + 1 != Size)
|
|
|
|
Name.append("\" \"");
|
|
|
|
}
|
|
|
|
Name.push_back('\"');
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, ClassRecord &Class) {
|
|
|
|
Name = Class.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, UnionRecord &Union) {
|
|
|
|
Name = Union.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, EnumRecord &Enum) {
|
|
|
|
Name = Enum.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, ArrayRecord &AT) {
|
|
|
|
Name = AT.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, VFTableRecord &VFT) {
|
|
|
|
Name = VFT.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, MemberFuncIdRecord &Id) {
|
|
|
|
Name = Id.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, ProcedureRecord &Proc) {
|
|
|
|
StringRef Ret = Types.getTypeName(Proc.getReturnType());
|
|
|
|
StringRef Params = Types.getTypeName(Proc.getArgumentList());
|
|
|
|
Name = formatv("{0} {1}", Ret, Params).sstr<256>();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
MemberFunctionRecord &MF) {
|
|
|
|
StringRef Ret = Types.getTypeName(MF.getReturnType());
|
|
|
|
StringRef Class = Types.getTypeName(MF.getClassType());
|
|
|
|
StringRef Params = Types.getTypeName(MF.getArgumentList());
|
|
|
|
Name = formatv("{0} {1}::{2}", Ret, Class, Params).sstr<256>();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, FuncIdRecord &Func) {
|
|
|
|
Name = Func.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, TypeServer2Record &TS) {
|
|
|
|
Name = TS.getName();
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, PointerRecord &Ptr) {
|
|
|
|
|
|
|
|
if (Ptr.isPointerToMember()) {
|
|
|
|
const MemberPointerInfo &MI = Ptr.getMemberInfo();
|
|
|
|
|
|
|
|
StringRef Pointee = Types.getTypeName(Ptr.getReferentType());
|
|
|
|
StringRef Class = Types.getTypeName(MI.getContainingType());
|
|
|
|
Name = formatv("{0} {1}::*", Pointee, Class);
|
|
|
|
} else {
|
|
|
|
Name.append(Types.getTypeName(Ptr.getReferentType()));
|
|
|
|
|
|
|
|
if (Ptr.getMode() == PointerMode::LValueReference)
|
|
|
|
Name.append("&");
|
|
|
|
else if (Ptr.getMode() == PointerMode::RValueReference)
|
|
|
|
Name.append("&&");
|
|
|
|
else if (Ptr.getMode() == PointerMode::Pointer)
|
|
|
|
Name.append("*");
|
|
|
|
|
|
|
|
// Qualifiers in pointer records apply to the pointer, not the pointee, so
|
|
|
|
// they go on the right.
|
|
|
|
if (Ptr.isConst())
|
|
|
|
Name.append(" const");
|
|
|
|
if (Ptr.isVolatile())
|
|
|
|
Name.append(" volatile");
|
|
|
|
if (Ptr.isUnaligned())
|
|
|
|
Name.append(" __unaligned");
|
|
|
|
if (Ptr.isRestrict())
|
|
|
|
Name.append(" __restrict");
|
|
|
|
}
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, ModifierRecord &Mod) {
|
|
|
|
uint16_t Mods = static_cast<uint16_t>(Mod.getModifiers());
|
|
|
|
|
|
|
|
if (Mods & uint16_t(ModifierOptions::Const))
|
|
|
|
Name.append("const ");
|
|
|
|
if (Mods & uint16_t(ModifierOptions::Volatile))
|
|
|
|
Name.append("volatile ");
|
|
|
|
if (Mods & uint16_t(ModifierOptions::Unaligned))
|
|
|
|
Name.append("__unaligned ");
|
|
|
|
Name.append(Types.getTypeName(Mod.getModifiedType()));
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
VFTableShapeRecord &Shape) {
|
|
|
|
Name = formatv("<vftable {0} methods>", Shape.getEntryCount());
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(
|
|
|
|
CVType &CVR, UdtModSourceLineRecord &ModSourceLine) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
UdtSourceLineRecord &SourceLine) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, BitFieldRecord &BF) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
MethodOverloadListRecord &Overloads) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, BuildInfoRecord &BI) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR, LabelRecord &R) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
PrecompRecord &Precomp) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
Error TypeNameComputer::visitKnownRecord(CVType &CVR,
|
|
|
|
EndPrecompRecord &EndPrecomp) {
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string llvm::codeview::computeTypeName(TypeCollection &Types,
|
|
|
|
TypeIndex Index) {
|
|
|
|
TypeNameComputer Computer(Types);
|
|
|
|
CVType Record = Types.getType(Index);
|
|
|
|
if (auto EC = visitTypeRecord(Record, Index, Computer)) {
|
|
|
|
consumeError(std::move(EC));
|
|
|
|
return "<unknown UDT>";
|
|
|
|
}
|
2020-01-28 20:23:46 +01:00
|
|
|
return std::string(Computer.name());
|
2018-04-10 02:09:15 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static int getSymbolNameOffset(CVSymbol Sym) {
|
|
|
|
switch (Sym.kind()) {
|
|
|
|
// See ProcSym
|
|
|
|
case SymbolKind::S_GPROC32:
|
|
|
|
case SymbolKind::S_LPROC32:
|
|
|
|
case SymbolKind::S_GPROC32_ID:
|
|
|
|
case SymbolKind::S_LPROC32_ID:
|
|
|
|
case SymbolKind::S_LPROC32_DPC:
|
|
|
|
case SymbolKind::S_LPROC32_DPC_ID:
|
|
|
|
return 35;
|
|
|
|
// See Thunk32Sym
|
|
|
|
case SymbolKind::S_THUNK32:
|
|
|
|
return 21;
|
|
|
|
// See SectionSym
|
|
|
|
case SymbolKind::S_SECTION:
|
|
|
|
return 16;
|
|
|
|
// See CoffGroupSym
|
|
|
|
case SymbolKind::S_COFFGROUP:
|
|
|
|
return 14;
|
|
|
|
// See PublicSym32, FileStaticSym, RegRelativeSym, DataSym, ThreadLocalDataSym
|
|
|
|
case SymbolKind::S_PUB32:
|
|
|
|
case SymbolKind::S_FILESTATIC:
|
|
|
|
case SymbolKind::S_REGREL32:
|
|
|
|
case SymbolKind::S_GDATA32:
|
|
|
|
case SymbolKind::S_LDATA32:
|
|
|
|
case SymbolKind::S_LMANDATA:
|
|
|
|
case SymbolKind::S_GMANDATA:
|
|
|
|
case SymbolKind::S_LTHREAD32:
|
|
|
|
case SymbolKind::S_GTHREAD32:
|
[CodeView] Correctly compute the name of S_PROCREF symbols.
We have a function which switches on the type of a symbol record
to return a hardcoded offset into the record that contains the
symbol name. Not all symbols have names to begin with, and for
those records we return -1 for the offset.
Names are used for various things. Importantly for this particular
bug, a hash of the record name is used as a key for certain hash
tables which are serialied into the PDB file. One of these hash
tables is for the global symbol stream, which is basically a
collection of S_PROCREF symbols which contain the name of the
symbol, a module, and an address offset.
However, for S_PROCREF symbols, the function to return the offset
of the name was returning -1: basically it wasn't implemented.
As a result of this, all global symbols were hashing to the same
value, essentially it was as if every single global symbol's name
was the empty string.
This manifests in the VS debugger when you try to call a function
(global or member, doesn't matter) through the immediate window
and the debugger simply reports an error because it can't find the
function. This makes perfect sense, because it is hashing the name
for real, looking in the global symbol hash table, and there is only
1 entry there which corresponds to a symbol whose name is the empty
string.
Fixing this fixes the MSVC debugger in this case.
llvm-svn: 336024
2018-06-30 00:19:02 +02:00
|
|
|
case SymbolKind::S_PROCREF:
|
|
|
|
case SymbolKind::S_LPROCREF:
|
2018-04-10 02:09:15 +02:00
|
|
|
return 10;
|
|
|
|
// See RegisterSym and LocalSym
|
|
|
|
case SymbolKind::S_REGISTER:
|
|
|
|
case SymbolKind::S_LOCAL:
|
|
|
|
return 6;
|
|
|
|
// See BlockSym
|
|
|
|
case SymbolKind::S_BLOCK32:
|
|
|
|
return 18;
|
|
|
|
// See LabelSym
|
|
|
|
case SymbolKind::S_LABEL32:
|
|
|
|
return 7;
|
|
|
|
// See ObjNameSym, ExportSym, and UDTSym
|
|
|
|
case SymbolKind::S_OBJNAME:
|
|
|
|
case SymbolKind::S_EXPORT:
|
|
|
|
case SymbolKind::S_UDT:
|
|
|
|
return 4;
|
|
|
|
// See BPRelativeSym
|
|
|
|
case SymbolKind::S_BPREL32:
|
|
|
|
return 8;
|
2018-07-31 21:15:50 +02:00
|
|
|
// See UsingNamespaceSym
|
|
|
|
case SymbolKind::S_UNAMESPACE:
|
|
|
|
return 0;
|
2018-04-10 02:09:15 +02:00
|
|
|
default:
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
StringRef llvm::codeview::getSymbolName(CVSymbol Sym) {
|
|
|
|
if (Sym.kind() == SymbolKind::S_CONSTANT) {
|
|
|
|
// S_CONSTANT is preceded by an APSInt, which has a variable length. So we
|
|
|
|
// have to do a full deserialization.
|
|
|
|
BinaryStreamReader Reader(Sym.content(), llvm::support::little);
|
|
|
|
// The container doesn't matter for single records.
|
|
|
|
SymbolRecordMapping Mapping(Reader, CodeViewContainer::ObjectFile);
|
|
|
|
ConstantSym Const(SymbolKind::S_CONSTANT);
|
|
|
|
cantFail(Mapping.visitSymbolBegin(Sym));
|
|
|
|
cantFail(Mapping.visitKnownRecord(Sym, Const));
|
|
|
|
cantFail(Mapping.visitSymbolEnd(Sym));
|
|
|
|
return Const.Name;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Offset = getSymbolNameOffset(Sym);
|
|
|
|
if (Offset == -1)
|
|
|
|
return StringRef();
|
|
|
|
|
|
|
|
StringRef StringData = toStringRef(Sym.content()).drop_front(Offset);
|
|
|
|
return StringData.split('\0').first;
|
|
|
|
}
|