2015-12-05 07:11:05 +08:00
|
|
|
//===- PDB.cpp ------------------------------------------------------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2015-12-05 07:11:05 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-09-16 06:24:51 +08:00
|
|
|
#include "PDB.h"
|
2016-11-12 08:00:51 +08:00
|
|
|
#include "Chunks.h"
|
2016-11-22 01:22:35 +08:00
|
|
|
#include "Config.h"
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
#include "DebugTypes.h"
|
2017-10-21 03:48:26 +08:00
|
|
|
#include "Driver.h"
|
2016-11-12 08:00:51 +08:00
|
|
|
#include "SymbolTable.h"
|
|
|
|
#include "Symbols.h"
|
2019-04-03 04:43:19 +08:00
|
|
|
#include "TypeMerger.h"
|
2017-07-28 02:25:59 +08:00
|
|
|
#include "Writer.h"
|
[lld] unified COFF and ELF error handling on new Common/ErrorHandler
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
2017-10-26 06:28:38 +08:00
|
|
|
#include "lld/Common/ErrorHandler.h"
|
2018-01-18 03:16:26 +08:00
|
|
|
#include "lld/Common/Timer.h"
|
2019-02-28 04:53:50 +08:00
|
|
|
#include "lld/Common/Threads.h"
|
2018-09-12 06:35:01 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/DebugFrameDataSubsection.h"
|
2017-06-20 01:21:45 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/DebugSubsectionRecord.h"
|
2017-12-15 02:07:04 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/GlobalTypeTableBuilder.h"
|
2017-05-20 03:26:58 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/LazyRandomTypeCollection.h"
|
2017-12-01 02:39:50 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/MergingTypeTableBuilder.h"
|
2017-08-12 03:00:03 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/RecordName.h"
|
2017-08-09 02:34:44 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/SymbolDeserializer.h"
|
2018-12-07 01:49:15 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/SymbolRecordHelpers.h"
|
2017-07-11 05:01:37 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/SymbolSerializer.h"
|
2017-07-18 08:21:25 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/TypeDeserializer.h"
|
[CodeView] Finish decoupling TypeDatabase from TypeDumper.
Previously the type dumper itself was passed around to a lot of different
places and manipulated in ways that were more appropriate on the type
database. For example, the entire TypeDumper was passed into the symbol
dumper, when all the symbol dumper wanted to do was lookup the name of a
TypeIndex so it could print it. That's what the TypeDatabase is for --
mapping type indices to names.
Another example is how if the user runs llvm-pdbdump with the option to
dump symbols but not types, we still have to visit all types so that we
can print minimal information about the type of a symbol, but just without
dumping full symbol records. The way we did this before is by hacking it
up so that we run everything through the type dumper with a null printer,
so that the output goes to /dev/null. But really, we don't need to dump
anything, all we want to do is build the type database. Since
TypeDatabaseVisitor now exists independently of TypeDumper, we can do
this. We just build a custom visitor callback pipeline that includes a
database visitor but not a dumper.
All the hackery around printers etc goes away. After this patch, we could
probably even delete the entire CVTypeDumper class since really all it is
at this point is a thin wrapper that hides the details of how to build a
useful visitation pipeline. It's not a priority though, so CVTypeDumper
remains for now.
After this patch we will be able to easily plug in a different style of
type dumper by only implementing the proper visitation methods to dump
one-line output and then sticking it on the pipeline.
Differential Revision: https://reviews.llvm.org/D28524
llvm-svn: 291724
2017-01-12 07:24:22 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/TypeDumpVisitor.h"
|
2017-06-22 01:25:56 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/TypeIndexDiscovery.h"
|
2017-01-12 11:09:25 +08:00
|
|
|
#include "llvm/DebugInfo/CodeView/TypeStreamMerger.h"
|
2016-09-16 12:32:33 +08:00
|
|
|
#include "llvm/DebugInfo/MSF/MSFBuilder.h"
|
2016-09-16 02:55:18 +08:00
|
|
|
#include "llvm/DebugInfo/MSF/MSFCommon.h"
|
2017-07-18 08:21:25 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/GenericError.h"
|
2017-07-11 05:01:37 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/DbiModuleDescriptorBuilder.h"
|
2017-01-26 06:38:55 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/DbiStream.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/Native/DbiStreamBuilder.h"
|
2017-08-09 12:23:25 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/GSIStreamBuilder.h"
|
2017-01-26 06:38:55 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/InfoStream.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/Native/InfoStreamBuilder.h"
|
2017-07-18 08:21:25 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/NativeSession.h"
|
2017-01-26 06:38:55 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/PDBFile.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/Native/PDBFileBuilder.h"
|
2017-05-03 04:19:42 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/PDBStringTableBuilder.h"
|
2017-07-20 01:26:07 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/TpiHashing.h"
|
2017-01-26 06:38:55 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/Native/TpiStream.h"
|
|
|
|
#include "llvm/DebugInfo/PDB/Native/TpiStreamBuilder.h"
|
2017-07-18 08:21:25 +08:00
|
|
|
#include "llvm/DebugInfo/PDB/PDB.h"
|
2016-11-01 05:09:21 +08:00
|
|
|
#include "llvm/Object/COFF.h"
|
2018-03-27 07:43:29 +08:00
|
|
|
#include "llvm/Object/CVDebugRecord.h"
|
2017-03-03 04:52:51 +08:00
|
|
|
#include "llvm/Support/BinaryByteStream.h"
|
2015-12-09 02:39:55 +08:00
|
|
|
#include "llvm/Support/Endian.h"
|
2018-11-06 03:20:47 +08:00
|
|
|
#include "llvm/Support/Errc.h"
|
2018-01-06 03:12:40 +08:00
|
|
|
#include "llvm/Support/FormatVariadic.h"
|
2017-08-08 04:23:45 +08:00
|
|
|
#include "llvm/Support/JamCRC.h"
|
2017-02-17 07:35:45 +08:00
|
|
|
#include "llvm/Support/Path.h"
|
2016-11-22 01:22:35 +08:00
|
|
|
#include "llvm/Support/ScopedPrinter.h"
|
2015-12-05 07:11:05 +08:00
|
|
|
#include <memory>
|
|
|
|
|
2016-09-16 06:24:51 +08:00
|
|
|
using namespace lld;
|
2016-11-12 08:00:51 +08:00
|
|
|
using namespace lld::coff;
|
2015-12-05 07:11:05 +08:00
|
|
|
using namespace llvm;
|
2016-11-22 01:22:35 +08:00
|
|
|
using namespace llvm::codeview;
|
2015-12-05 07:11:05 +08:00
|
|
|
|
2016-11-12 08:00:51 +08:00
|
|
|
using llvm::object::coff_section;
|
|
|
|
|
2016-09-16 12:32:33 +08:00
|
|
|
static ExitOnError ExitOnErr;
|
|
|
|
|
2018-01-18 03:16:26 +08:00
|
|
|
static Timer TotalPdbLinkTimer("PDB Emission (Cumulative)", Timer::root());
|
|
|
|
|
|
|
|
static Timer AddObjectsTimer("Add Objects", TotalPdbLinkTimer);
|
|
|
|
static Timer TypeMergingTimer("Type Merging", AddObjectsTimer);
|
|
|
|
static Timer SymbolMergingTimer("Symbol Merging", AddObjectsTimer);
|
|
|
|
static Timer GlobalsLayoutTimer("Globals Stream Layout", TotalPdbLinkTimer);
|
|
|
|
static Timer TpiStreamLayoutTimer("TPI Stream Layout", TotalPdbLinkTimer);
|
|
|
|
static Timer DiskCommitTimer("Commit to Disk", TotalPdbLinkTimer);
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
namespace {
|
2018-09-13 05:02:01 +08:00
|
|
|
class DebugSHandler;
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
class PDBLinker {
|
2018-09-13 05:02:01 +08:00
|
|
|
friend DebugSHandler;
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
public:
|
|
|
|
PDBLinker(SymbolTable *Symtab)
|
2019-04-03 04:43:19 +08:00
|
|
|
: Alloc(), Symtab(Symtab), Builder(Alloc), TMerger(Alloc) {
|
2018-03-24 02:43:39 +08:00
|
|
|
// This isn't strictly necessary, but link.exe usually puts an empty string
|
|
|
|
// as the first "valid" string in the string table, so we do the same in
|
|
|
|
// order to maintain as much byte-for-byte compatibility as possible.
|
|
|
|
PDBStrTab.insert("");
|
|
|
|
}
|
2017-07-14 08:14:58 +08:00
|
|
|
|
|
|
|
/// Emit the basic PDB structure: initial streams, headers, etc.
|
2018-09-16 02:37:22 +08:00
|
|
|
void initialize(llvm::codeview::DebugInfo *BuildId);
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2018-03-24 03:57:25 +08:00
|
|
|
/// Add natvis files specified on the command line.
|
|
|
|
void addNatvisFiles();
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
/// Link CodeView from each object file in the symbol table into the PDB.
|
|
|
|
void addObjectsToPDB();
|
|
|
|
|
2019-03-30 04:25:34 +08:00
|
|
|
/// Link info for each import file in the symbol table into the PDB.
|
|
|
|
void addImportFilesToPDB(ArrayRef<OutputSection *> OutputSections);
|
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
/// Link CodeView from a single object file into the target (output) PDB.
|
|
|
|
/// When a precompiled headers object is linked, its TPI map might be provided
|
|
|
|
/// externally.
|
|
|
|
void addObjFile(ObjFile *File, CVIndexMap *ExternIndexMap = nullptr);
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2017-07-18 08:21:25 +08:00
|
|
|
/// Produce a mapping from the type and item indices used in the object
|
|
|
|
/// file to those in the destination PDB.
|
|
|
|
///
|
|
|
|
/// If the object file uses a type server PDB (compiled with /Zi), merge TPI
|
|
|
|
/// and IPI from the type server PDB and return a map for it. Each unique type
|
|
|
|
/// server PDB is merged at most once, so this may return an existing index
|
|
|
|
/// mapping.
|
|
|
|
///
|
|
|
|
/// If the object does not use a type server PDB (compiled with /Z7), we merge
|
|
|
|
/// all the type and item records from the .debug$S stream and fill in the
|
|
|
|
/// caller-provided ObjectIndexMap.
|
2018-11-06 03:20:47 +08:00
|
|
|
Expected<const CVIndexMap &> mergeDebugT(ObjFile *File,
|
|
|
|
CVIndexMap *ObjectIndexMap);
|
2017-07-18 08:21:25 +08:00
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
/// Reads and makes available a PDB.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Expected<const CVIndexMap &> maybeMergeTypeServerPDB(ObjFile *File);
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
/// Merges a precompiled headers TPI map into the current TPI map. The
|
|
|
|
/// precompiled headers object will also be loaded and remapped in the
|
|
|
|
/// process.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Error mergeInPrecompHeaderObj(ObjFile *File, CVIndexMap *ObjectIndexMap);
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
/// Reads and makes available a precompiled headers object.
|
|
|
|
///
|
|
|
|
/// This is a requirement for objects compiled with cl.exe /Yu. In that
|
|
|
|
/// case, the referenced object (which was compiled with /Yc) has to be loaded
|
|
|
|
/// first. This is mainly because the current object's TPI stream has external
|
|
|
|
/// references to the precompiled headers object.
|
|
|
|
///
|
|
|
|
/// If the precompiled headers object was already loaded, this function will
|
|
|
|
/// simply return its (remapped) TPI map.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Expected<const CVIndexMap &> aquirePrecompObj(ObjFile *File);
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
/// Adds a precompiled headers object signature -> TPI mapping.
|
|
|
|
std::pair<CVIndexMap &, bool /*already there*/>
|
|
|
|
registerPrecompiledHeaders(uint32_t Signature);
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2018-11-14 07:44:39 +08:00
|
|
|
void mergeSymbolRecords(ObjFile *File, const CVIndexMap &IndexMap,
|
|
|
|
std::vector<ulittle32_t *> &StringTableRefs,
|
|
|
|
BinaryStreamRef SymData);
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
/// Add the section map and section contributions to the PDB.
|
2017-08-04 05:15:09 +08:00
|
|
|
void addSections(ArrayRef<OutputSection *> OutputSections,
|
|
|
|
ArrayRef<uint8_t> SectionTable);
|
|
|
|
|
2018-09-16 02:37:22 +08:00
|
|
|
/// Write the PDB to disk and store the Guid generated for it in *Guid.
|
|
|
|
void commit(codeview::GUID *Guid);
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2019-03-15 02:45:08 +08:00
|
|
|
// Print statistics regarding the final PDB
|
|
|
|
void printStats();
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
private:
|
|
|
|
BumpPtrAllocator Alloc;
|
|
|
|
|
|
|
|
SymbolTable *Symtab;
|
|
|
|
|
|
|
|
pdb::PDBFileBuilder Builder;
|
|
|
|
|
2019-04-03 04:43:19 +08:00
|
|
|
TypeMerger TMerger;
|
2017-12-15 02:07:04 +08:00
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
/// PDBs use a single global string table for filenames in the file checksum
|
|
|
|
/// table.
|
|
|
|
DebugStringTableSubsection PDBStrTab;
|
|
|
|
|
|
|
|
llvm::SmallString<128> NativePath;
|
|
|
|
|
|
|
|
std::vector<pdb::SecMapEntry> SectionMap;
|
2017-07-18 08:21:25 +08:00
|
|
|
|
|
|
|
/// Type index mappings of type server PDBs that we've loaded so far.
|
2019-01-05 09:08:10 +08:00
|
|
|
std::map<codeview::GUID, CVIndexMap> TypeServerIndexMappings;
|
2018-02-01 01:48:04 +08:00
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
/// Type index mappings of precompiled objects type map that we've loaded so
|
|
|
|
/// far.
|
|
|
|
std::map<uint32_t, CVIndexMap> PrecompTypeIndexMappings;
|
|
|
|
|
2019-03-15 02:45:08 +08:00
|
|
|
// For statistics
|
|
|
|
uint64_t GlobalSymbols = 0;
|
|
|
|
uint64_t ModuleSymbols = 0;
|
|
|
|
uint64_t PublicSymbols = 0;
|
2017-07-14 08:14:58 +08:00
|
|
|
};
|
2018-09-13 05:02:01 +08:00
|
|
|
|
|
|
|
class DebugSHandler {
|
|
|
|
PDBLinker &Linker;
|
|
|
|
|
|
|
|
/// The object file whose .debug$S sections we're processing.
|
|
|
|
ObjFile &File;
|
|
|
|
|
|
|
|
/// The result of merging type indices.
|
|
|
|
const CVIndexMap &IndexMap;
|
|
|
|
|
|
|
|
/// The DEBUG_S_STRINGTABLE subsection. These strings are referred to by
|
|
|
|
/// index from other records in the .debug$S section. All of these strings
|
|
|
|
/// need to be added to the global PDB string table, and all references to
|
|
|
|
/// these strings need to have their indices re-written to refer to the
|
|
|
|
/// global PDB string table.
|
|
|
|
DebugStringTableSubsectionRef CVStrTab;
|
|
|
|
|
|
|
|
/// The DEBUG_S_FILECHKSMS subsection. As above, these are referred to
|
|
|
|
/// by other records in the .debug$S section and need to be merged into the
|
|
|
|
/// PDB.
|
|
|
|
DebugChecksumsSubsectionRef Checksums;
|
|
|
|
|
2019-06-04 02:15:38 +08:00
|
|
|
/// The DEBUG_S_INLINEELINES subsection. There can be only one of these per
|
|
|
|
/// object file.
|
|
|
|
DebugInlineeLinesSubsectionRef InlineeLines;
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
/// The DEBUG_S_FRAMEDATA subsection(s). There can be more than one of
|
|
|
|
/// these and they need not appear in any specific order. However, they
|
|
|
|
/// contain string table references which need to be re-written, so we
|
|
|
|
/// collect them all here and re-write them after all subsections have been
|
|
|
|
/// discovered and processed.
|
|
|
|
std::vector<DebugFrameDataSubsectionRef> NewFpoFrames;
|
|
|
|
|
|
|
|
/// Pointers to raw memory that we determine have string table references
|
|
|
|
/// that need to be re-written. We first process all .debug$S subsections
|
|
|
|
/// to ensure that we can handle subsections written in any order, building
|
|
|
|
/// up this list as we go. At the end, we use the string table (which must
|
|
|
|
/// have been discovered by now else it is an error) to re-write these
|
|
|
|
/// references.
|
|
|
|
std::vector<ulittle32_t *> StringTableReferences;
|
|
|
|
|
|
|
|
public:
|
|
|
|
DebugSHandler(PDBLinker &Linker, ObjFile &File, const CVIndexMap &IndexMap)
|
|
|
|
: Linker(Linker), File(File), IndexMap(IndexMap) {}
|
|
|
|
|
|
|
|
void handleDebugS(lld::coff::SectionChunk &DebugS);
|
2019-06-04 02:15:38 +08:00
|
|
|
|
|
|
|
std::shared_ptr<DebugInlineeLinesSubsection>
|
|
|
|
mergeInlineeLines(DebugChecksumsSubsection *NewChecksums);
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
void finish();
|
|
|
|
};
|
2017-07-14 08:14:58 +08:00
|
|
|
}
|
|
|
|
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
// Visual Studio's debugger requires absolute paths in various places in the
|
|
|
|
// PDB to work without additional configuration:
|
|
|
|
// https://docs.microsoft.com/en-us/visualstudio/debugger/debug-source-files-common-properties-solution-property-pages-dialog-box
|
|
|
|
static void pdbMakeAbsolute(SmallVectorImpl<char> &FileName) {
|
2018-10-13 01:26:19 +08:00
|
|
|
// The default behavior is to produce paths that are valid within the context
|
|
|
|
// of the machine that you perform the link on. If the linker is running on
|
|
|
|
// a POSIX system, we will output absolute POSIX paths. If the linker is
|
|
|
|
// running on a Windows system, we will output absolute Windows paths. If the
|
|
|
|
// user desires any other kind of behavior, they should explicitly pass
|
|
|
|
// /pdbsourcepath, in which case we will treat the exact string the user
|
|
|
|
// passed in as the gospel and not normalize, canonicalize it.
|
|
|
|
if (sys::path::is_absolute(FileName, sys::path::Style::windows) ||
|
|
|
|
sys::path::is_absolute(FileName, sys::path::Style::posix))
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
return;
|
2018-10-13 01:26:19 +08:00
|
|
|
|
|
|
|
// It's not absolute in any path syntax. Relative paths necessarily refer to
|
|
|
|
// the local file system, so we can make it native without ending up with a
|
|
|
|
// nonsensical path.
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
if (Config->PDBSourcePath.empty()) {
|
2019-02-06 08:50:35 +08:00
|
|
|
sys::path::native(FileName);
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
sys::fs::make_absolute(FileName);
|
|
|
|
return;
|
|
|
|
}
|
2018-10-13 01:26:19 +08:00
|
|
|
|
2019-02-06 08:50:35 +08:00
|
|
|
// Try to guess whether /PDBSOURCEPATH is a unix path or a windows path.
|
|
|
|
// Since PDB's are more of a Windows thing, we make this conservative and only
|
|
|
|
// decide that it's a unix path if we're fairly certain. Specifically, if
|
|
|
|
// it starts with a forward slash.
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
SmallString<128> AbsoluteFileName = Config->PDBSourcePath;
|
2019-02-06 08:50:35 +08:00
|
|
|
sys::path::Style GuessedStyle = AbsoluteFileName.startswith("/")
|
|
|
|
? sys::path::Style::posix
|
|
|
|
: sys::path::Style::windows;
|
|
|
|
sys::path::append(AbsoluteFileName, GuessedStyle, FileName);
|
|
|
|
sys::path::native(AbsoluteFileName, GuessedStyle);
|
|
|
|
sys::path::remove_dots(AbsoluteFileName, true, GuessedStyle);
|
|
|
|
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
FileName = std::move(AbsoluteFileName);
|
|
|
|
}
|
|
|
|
|
2017-12-15 02:07:04 +08:00
|
|
|
// A COFF .debug$H section is currently a clang extension. This function checks
|
|
|
|
// if a .debug$H section is in a format that we expect / understand, so that we
|
|
|
|
// can ignore any sections which are coincidentally also named .debug$H but do
|
|
|
|
// not contain a format we recognize.
|
|
|
|
static bool canUseDebugH(ArrayRef<uint8_t> DebugH) {
|
|
|
|
if (DebugH.size() < sizeof(object::debug_h_header))
|
|
|
|
return false;
|
|
|
|
auto *Header =
|
|
|
|
reinterpret_cast<const object::debug_h_header *>(DebugH.data());
|
|
|
|
DebugH = DebugH.drop_front(sizeof(object::debug_h_header));
|
|
|
|
return Header->Magic == COFF::DEBUG_HASHES_SECTION_MAGIC &&
|
|
|
|
Header->Version == 0 &&
|
2018-05-18 06:55:15 +08:00
|
|
|
Header->HashAlgorithm == uint16_t(GlobalTypeHashAlg::SHA1_8) &&
|
|
|
|
(DebugH.size() % 8 == 0);
|
2017-12-15 02:07:04 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static Optional<ArrayRef<uint8_t>> getDebugH(ObjFile *File) {
|
2019-02-23 09:46:18 +08:00
|
|
|
SectionChunk *Sec =
|
|
|
|
SectionChunk::findByName(File->getDebugChunks(), ".debug$H");
|
2017-12-15 02:07:04 +08:00
|
|
|
if (!Sec)
|
|
|
|
return llvm::None;
|
|
|
|
ArrayRef<uint8_t> Contents = Sec->getContents();
|
|
|
|
if (!canUseDebugH(Contents))
|
|
|
|
return None;
|
|
|
|
return Contents;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ArrayRef<GloballyHashedType>
|
|
|
|
getHashesFromDebugH(ArrayRef<uint8_t> DebugH) {
|
|
|
|
assert(canUseDebugH(DebugH));
|
|
|
|
|
|
|
|
DebugH = DebugH.drop_front(sizeof(object::debug_h_header));
|
|
|
|
uint32_t Count = DebugH.size() / sizeof(GloballyHashedType);
|
|
|
|
return {reinterpret_cast<const GloballyHashedType *>(DebugH.data()), Count};
|
|
|
|
}
|
|
|
|
|
2017-03-25 01:26:38 +08:00
|
|
|
static void addTypeInfo(pdb::TpiStreamBuilder &TpiBuilder,
|
2017-11-30 03:35:21 +08:00
|
|
|
TypeCollection &TypeTable) {
|
2017-03-25 01:26:38 +08:00
|
|
|
// Start the TPI or IPI stream header.
|
|
|
|
TpiBuilder.setVersionHeader(pdb::PdbTpiV80);
|
|
|
|
|
2017-07-20 01:26:07 +08:00
|
|
|
// Flatten the in memory type table and hash each type.
|
2017-11-30 03:35:21 +08:00
|
|
|
TypeTable.ForEachRecord([&](TypeIndex TI, const CVType &Type) {
|
2017-07-20 01:26:07 +08:00
|
|
|
auto Hash = pdb::hashTypeRecord(Type);
|
|
|
|
if (auto E = Hash.takeError())
|
|
|
|
fatal("type hashing error");
|
2017-11-30 03:35:21 +08:00
|
|
|
TpiBuilder.addTypeRecord(Type.RecordData, *Hash);
|
2017-03-25 01:26:38 +08:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
Expected<const CVIndexMap &>
|
|
|
|
PDBLinker::mergeDebugT(ObjFile *File, CVIndexMap *ObjectIndexMap) {
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T(TypeMergingTimer);
|
|
|
|
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
if (!File->DebugTypesObj)
|
2019-06-03 20:39:47 +08:00
|
|
|
return *ObjectIndexMap; // no Types stream
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
// Precompiled headers objects need to save the index map for further
|
|
|
|
// reference by other objects which use the precompiled headers.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
if (File->DebugTypesObj->Kind == TpiSource::PCH) {
|
2019-02-23 09:46:18 +08:00
|
|
|
uint32_t PCHSignature = File->PCHSignature.getValueOr(0);
|
2018-11-06 03:20:47 +08:00
|
|
|
if (PCHSignature == 0)
|
|
|
|
fatal("No signature found for the precompiled headers OBJ (" +
|
|
|
|
File->getName() + ")");
|
|
|
|
|
|
|
|
// When a precompiled headers object comes first on the command-line, we
|
|
|
|
// update the mapping here. Otherwise, if an object referencing the
|
|
|
|
// precompiled headers object comes first, the mapping is created in
|
|
|
|
// aquirePrecompObj(), thus we would skip this block.
|
|
|
|
if (!ObjectIndexMap->IsPrecompiledTypeMap) {
|
|
|
|
auto R = registerPrecompiledHeaders(PCHSignature);
|
|
|
|
if (R.second)
|
|
|
|
fatal(
|
|
|
|
"A precompiled headers OBJ with the same signature was already "
|
|
|
|
"provided! (" +
|
|
|
|
File->getName() + ")");
|
|
|
|
|
|
|
|
ObjectIndexMap = &R.first;
|
|
|
|
}
|
|
|
|
}
|
2017-07-14 04:12:23 +08:00
|
|
|
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
if (File->DebugTypesObj->Kind == TpiSource::UsingPDB) {
|
2018-11-06 03:20:47 +08:00
|
|
|
// Look through type servers. If we've already seen this type server,
|
|
|
|
// don't merge any type information.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
return maybeMergeTypeServerPDB(File);
|
|
|
|
}
|
|
|
|
|
|
|
|
CVTypeArray &Types = *File->DebugTypes;
|
|
|
|
|
|
|
|
if (File->DebugTypesObj->Kind == TpiSource::UsingPCH) {
|
2018-11-06 03:20:47 +08:00
|
|
|
// This object was compiled with /Yu, so process the corresponding
|
|
|
|
// precompiled headers object (/Yc) first. Some type indices in the current
|
|
|
|
// object are referencing data in the precompiled headers object, so we need
|
|
|
|
// both to be loaded.
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Error E = mergeInPrecompHeaderObj(File, ObjectIndexMap);
|
|
|
|
if (E)
|
|
|
|
return std::move(E);
|
|
|
|
|
|
|
|
// Drop LF_PRECOMP record from the input stream, as it has been replaced
|
|
|
|
// with the precompiled headers Type stream in the mergeInPrecompHeaderObj()
|
|
|
|
// call above. Note that we can't just call Types.drop_front(), as we
|
|
|
|
// explicitly want to rebase the stream.
|
|
|
|
CVTypeArray::Iterator FirstType = Types.begin();
|
2018-12-14 02:11:33 +08:00
|
|
|
Types.setUnderlyingStream(
|
|
|
|
Types.getUnderlyingStream().drop_front(FirstType->RecordData.size()));
|
2018-11-06 03:20:47 +08:00
|
|
|
}
|
2017-07-18 08:21:25 +08:00
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
// Fill in the temporary, caller-provided ObjectIndexMap.
|
2017-12-15 02:07:04 +08:00
|
|
|
if (Config->DebugGHashes) {
|
|
|
|
ArrayRef<GloballyHashedType> Hashes;
|
|
|
|
std::vector<GloballyHashedType> OwnedHashes;
|
|
|
|
if (Optional<ArrayRef<uint8_t>> DebugH = getDebugH(File))
|
|
|
|
Hashes = getHashesFromDebugH(*DebugH);
|
|
|
|
else {
|
|
|
|
OwnedHashes = GloballyHashedType::hashTypes(Types);
|
|
|
|
Hashes = OwnedHashes;
|
|
|
|
}
|
|
|
|
|
2019-04-03 04:43:19 +08:00
|
|
|
if (auto Err = mergeTypeAndIdRecords(
|
|
|
|
TMerger.GlobalIDTable, TMerger.GlobalTypeTable,
|
|
|
|
ObjectIndexMap->TPIMap, Types, Hashes, File->PCHSignature))
|
2017-12-15 02:07:04 +08:00
|
|
|
fatal("codeview::mergeTypeAndIdRecords failed: " +
|
|
|
|
toString(std::move(Err)));
|
|
|
|
} else {
|
2019-04-03 04:43:19 +08:00
|
|
|
if (auto Err = mergeTypeAndIdRecords(TMerger.IDTable, TMerger.TypeTable,
|
|
|
|
ObjectIndexMap->TPIMap, Types,
|
|
|
|
File->PCHSignature))
|
2017-12-15 02:07:04 +08:00
|
|
|
fatal("codeview::mergeTypeAndIdRecords failed: " +
|
|
|
|
toString(std::move(Err)));
|
|
|
|
}
|
2018-11-06 03:20:47 +08:00
|
|
|
return *ObjectIndexMap;
|
2017-07-18 08:21:25 +08:00
|
|
|
}
|
|
|
|
|
2019-05-29 04:57:56 +08:00
|
|
|
Expected<const CVIndexMap &> PDBLinker::maybeMergeTypeServerPDB(ObjFile *File) {
|
2019-06-03 20:39:47 +08:00
|
|
|
Expected<llvm::pdb::NativeSession *> PDBSession = findTypeServerSource(File);
|
|
|
|
if (!PDBSession)
|
|
|
|
return PDBSession.takeError();
|
2018-03-01 02:09:18 +08:00
|
|
|
|
2019-06-03 20:39:47 +08:00
|
|
|
pdb::PDBFile &PDBFile = PDBSession.get()->getPDBFile();
|
|
|
|
pdb::InfoStream &Info = cantFail(PDBFile.getPDBInfoStream());
|
2019-05-29 04:57:56 +08:00
|
|
|
|
2019-06-03 20:39:47 +08:00
|
|
|
auto It = TypeServerIndexMappings.emplace(Info.getGuid(), CVIndexMap());
|
|
|
|
CVIndexMap &IndexMap = It.first->second;
|
|
|
|
if (!It.second)
|
|
|
|
return IndexMap; // already merged
|
2019-05-29 04:57:56 +08:00
|
|
|
|
2019-06-03 20:39:47 +08:00
|
|
|
// Mark this map as a type server map.
|
|
|
|
IndexMap.IsTypeServerMap = true;
|
2019-05-29 04:57:56 +08:00
|
|
|
|
2019-06-03 20:39:47 +08:00
|
|
|
Expected<pdb::TpiStream &> ExpectedTpi = PDBFile.getPDBTpiStream();
|
2017-07-18 08:21:25 +08:00
|
|
|
if (auto E = ExpectedTpi.takeError())
|
[lld] unified COFF and ELF error handling on new Common/ErrorHandler
Summary:
The COFF linker and the ELF linker have long had similar but separate
Error.h and Error.cpp files to implement error handling. This change
introduces new error handling code in Common/ErrorHandler.h, changes the
COFF and ELF linkers to use it, and removes the old, separate
implementations.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: smeenai, jyknight, emaste, sdardis, nemanjai, nhaehnle, mgorny, javed.absar, kbarton, fedor.sergeev, llvm-commits
Differential Revision: https://reviews.llvm.org/D39259
llvm-svn: 316624
2017-10-26 06:28:38 +08:00
|
|
|
fatal("Type server does not have TPI stream: " + toString(std::move(E)));
|
2019-06-13 06:33:16 +08:00
|
|
|
pdb::TpiStream *MaybeIpi = nullptr;
|
|
|
|
if (PDBFile.hasPDBIpiStream()) {
|
|
|
|
Expected<pdb::TpiStream &> ExpectedIpi = PDBFile.getPDBIpiStream();
|
|
|
|
if (auto E = ExpectedIpi.takeError())
|
|
|
|
fatal("Error getting type server IPI stream: " + toString(std::move(E)));
|
|
|
|
MaybeIpi = &*ExpectedIpi;
|
|
|
|
}
|
2017-12-15 02:07:04 +08:00
|
|
|
|
|
|
|
if (Config->DebugGHashes) {
|
|
|
|
// PDBs do not actually store global hashes, so when merging a type server
|
|
|
|
// PDB we have to synthesize global hashes. To do this, we first synthesize
|
|
|
|
// global hashes for the TPI stream, since it is independent, then we
|
|
|
|
// synthesize hashes for the IPI stream, using the hashes for the TPI stream
|
|
|
|
// as inputs.
|
|
|
|
auto TpiHashes = GloballyHashedType::hashTypes(ExpectedTpi->typeArray());
|
2019-01-07 21:53:16 +08:00
|
|
|
Optional<uint32_t> EndPrecomp;
|
2017-12-15 02:07:04 +08:00
|
|
|
// Merge TPI first, because the IPI stream will reference type indices.
|
2019-04-03 04:43:19 +08:00
|
|
|
if (auto Err =
|
|
|
|
mergeTypeRecords(TMerger.GlobalTypeTable, IndexMap.TPIMap,
|
|
|
|
ExpectedTpi->typeArray(), TpiHashes, EndPrecomp))
|
2017-12-15 02:07:04 +08:00
|
|
|
fatal("codeview::mergeTypeRecords failed: " + toString(std::move(Err)));
|
|
|
|
|
|
|
|
// Merge IPI.
|
2019-06-13 06:33:16 +08:00
|
|
|
if (MaybeIpi) {
|
|
|
|
auto IpiHashes =
|
|
|
|
GloballyHashedType::hashIds(MaybeIpi->typeArray(), TpiHashes);
|
|
|
|
if (auto Err =
|
|
|
|
mergeIdRecords(TMerger.GlobalIDTable, IndexMap.TPIMap,
|
|
|
|
IndexMap.IPIMap, MaybeIpi->typeArray(), IpiHashes))
|
|
|
|
fatal("codeview::mergeIdRecords failed: " + toString(std::move(Err)));
|
|
|
|
}
|
2017-12-15 02:07:04 +08:00
|
|
|
} else {
|
|
|
|
// Merge TPI first, because the IPI stream will reference type indices.
|
2019-04-03 04:43:19 +08:00
|
|
|
if (auto Err = mergeTypeRecords(TMerger.TypeTable, IndexMap.TPIMap,
|
2017-12-15 02:07:04 +08:00
|
|
|
ExpectedTpi->typeArray()))
|
|
|
|
fatal("codeview::mergeTypeRecords failed: " + toString(std::move(Err)));
|
|
|
|
|
|
|
|
// Merge IPI.
|
2019-06-13 06:33:16 +08:00
|
|
|
if (MaybeIpi) {
|
|
|
|
if (auto Err = mergeIdRecords(TMerger.IDTable, IndexMap.TPIMap,
|
|
|
|
IndexMap.IPIMap, MaybeIpi->typeArray()))
|
|
|
|
fatal("codeview::mergeIdRecords failed: " + toString(std::move(Err)));
|
|
|
|
}
|
2017-12-15 02:07:04 +08:00
|
|
|
}
|
2017-07-18 08:21:25 +08:00
|
|
|
|
|
|
|
return IndexMap;
|
2017-06-20 01:21:45 +08:00
|
|
|
}
|
|
|
|
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Error PDBLinker::mergeInPrecompHeaderObj(ObjFile *File,
|
|
|
|
CVIndexMap *ObjectIndexMap) {
|
|
|
|
const PrecompRecord &Precomp =
|
|
|
|
retrieveDependencyInfo<PrecompRecord>(File->DebugTypesObj);
|
|
|
|
|
|
|
|
Expected<const CVIndexMap &> E = aquirePrecompObj(File);
|
2018-11-06 03:20:47 +08:00
|
|
|
if (!E)
|
2018-11-08 22:42:37 +08:00
|
|
|
return E.takeError();
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
const CVIndexMap &PrecompIndexMap = *E;
|
|
|
|
assert(PrecompIndexMap.IsPrecompiledTypeMap);
|
|
|
|
|
|
|
|
if (PrecompIndexMap.TPIMap.empty())
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
return Error::success();
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
assert(Precomp.getStartTypeIndex() == TypeIndex::FirstNonSimpleIndex);
|
|
|
|
assert(Precomp.getTypesCount() <= PrecompIndexMap.TPIMap.size());
|
|
|
|
// Use the previously remapped index map from the precompiled headers.
|
|
|
|
ObjectIndexMap->TPIMap.append(PrecompIndexMap.TPIMap.begin(),
|
|
|
|
PrecompIndexMap.TPIMap.begin() +
|
|
|
|
Precomp.getTypesCount());
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
return Error::success();
|
2018-11-06 03:20:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool equals_path(StringRef path1, StringRef path2) {
|
|
|
|
#if defined(_WIN32)
|
|
|
|
return path1.equals_lower(path2);
|
|
|
|
#else
|
|
|
|
return path1.equals(path2);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2018-11-08 22:42:37 +08:00
|
|
|
// Find by name an OBJ provided on the command line
|
|
|
|
static ObjFile *findObjByName(StringRef FileNameOnly) {
|
2018-11-06 03:20:47 +08:00
|
|
|
SmallString<128> CurrentPath;
|
|
|
|
|
|
|
|
for (ObjFile *F : ObjFile::Instances) {
|
2018-11-08 22:42:37 +08:00
|
|
|
StringRef CurrentFileName = sys::path::filename(F->getName());
|
2018-11-06 03:20:47 +08:00
|
|
|
|
2018-11-08 22:42:37 +08:00
|
|
|
// Compare based solely on the file name (link.exe behavior)
|
2018-11-06 03:20:47 +08:00
|
|
|
if (equals_path(CurrentFileName, FileNameOnly))
|
2018-11-08 22:42:37 +08:00
|
|
|
return F;
|
2018-11-06 03:20:47 +08:00
|
|
|
}
|
2018-11-08 22:42:37 +08:00
|
|
|
return nullptr;
|
2018-11-06 03:20:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
std::pair<CVIndexMap &, bool /*already there*/>
|
|
|
|
PDBLinker::registerPrecompiledHeaders(uint32_t Signature) {
|
|
|
|
auto Insertion = PrecompTypeIndexMappings.insert({Signature, CVIndexMap()});
|
|
|
|
CVIndexMap &IndexMap = Insertion.first->second;
|
|
|
|
if (!Insertion.second)
|
|
|
|
return {IndexMap, true};
|
|
|
|
// Mark this map as a precompiled types map.
|
|
|
|
IndexMap.IsPrecompiledTypeMap = true;
|
|
|
|
return {IndexMap, false};
|
|
|
|
}
|
|
|
|
|
[LLD][COFF] Early dependency detection
We introduce a new class hierarchy for debug types merging (in DebugTypes.h). The end-goal is to parallelize the type merging - please see the plan in D59226.
Previously, dependency discovery was done on the fly, much later, during the type merging loop. Unfortunately, parallelizing the type merging requires the dependencies to be merged in first, before any dependent ObjFile, thus this early discovery.
The overall intention for this path is to discover debug information dependencies at a much earlier stage, when processing input files. Currently, two types of dependency are supported: PDB type servers (when compiling with MSVC /Zi) and precompiled headers OBJs (when compiling with MSVC /Yc and /Yu). Once discovered, an explicit link is added into the dependent ObjFile, through the new debug types class hierarchy introduced in DebugTypes.h.
Differential Revision: https://reviews.llvm.org/D59053
llvm-svn: 357383
2019-04-01 21:36:59 +08:00
|
|
|
Expected<const CVIndexMap &> PDBLinker::aquirePrecompObj(ObjFile *File) {
|
|
|
|
const PrecompRecord &Precomp =
|
|
|
|
retrieveDependencyInfo<PrecompRecord>(File->DebugTypesObj);
|
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
// First, check if we already loaded the precompiled headers object with this
|
|
|
|
// signature. Return the type index mapping if we've already seen it.
|
|
|
|
auto R = registerPrecompiledHeaders(Precomp.getSignature());
|
|
|
|
if (R.second)
|
|
|
|
return R.first;
|
|
|
|
|
|
|
|
CVIndexMap &IndexMap = R.first;
|
|
|
|
|
|
|
|
// Cross-compile warning: given that Clang doesn't generate LF_PRECOMP
|
|
|
|
// records, we assume the OBJ comes from a Windows build of cl.exe. Thusly,
|
|
|
|
// the paths embedded in the OBJs are in the Windows format.
|
2018-11-08 22:42:37 +08:00
|
|
|
SmallString<128> PrecompFileName = sys::path::filename(
|
|
|
|
Precomp.getPrecompFilePath(), sys::path::Style::windows);
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
// link.exe requires that a precompiled headers object must always be provided
|
|
|
|
// on the command-line, even if that's not necessary.
|
2018-11-08 22:42:37 +08:00
|
|
|
auto PrecompFile = findObjByName(PrecompFileName);
|
|
|
|
if (!PrecompFile)
|
|
|
|
return createFileError(
|
|
|
|
PrecompFileName.str(),
|
|
|
|
make_error<pdb::PDBError>(pdb::pdb_error_code::external_cmdline_ref));
|
2018-11-06 03:20:47 +08:00
|
|
|
|
2018-11-08 22:42:37 +08:00
|
|
|
addObjFile(PrecompFile, &IndexMap);
|
2018-11-06 03:20:47 +08:00
|
|
|
|
2019-01-07 21:53:16 +08:00
|
|
|
if (!PrecompFile->PCHSignature)
|
2018-11-08 22:42:37 +08:00
|
|
|
fatal(PrecompFile->getName() + " is not a precompiled headers object");
|
2018-11-06 03:20:47 +08:00
|
|
|
|
2019-01-07 21:53:16 +08:00
|
|
|
if (Precomp.getSignature() != PrecompFile->PCHSignature.getValueOr(0))
|
2018-11-08 22:42:37 +08:00
|
|
|
return createFileError(
|
|
|
|
Precomp.getPrecompFilePath().str(),
|
|
|
|
make_error<pdb::PDBError>(pdb::pdb_error_code::signature_out_of_date));
|
2018-11-06 03:20:47 +08:00
|
|
|
|
|
|
|
return IndexMap;
|
|
|
|
}
|
|
|
|
|
2017-06-22 01:25:56 +08:00
|
|
|
static bool remapTypeIndex(TypeIndex &TI, ArrayRef<TypeIndex> TypeIndexMap) {
|
|
|
|
if (TI.isSimple())
|
|
|
|
return true;
|
|
|
|
if (TI.toArrayIndex() >= TypeIndexMap.size())
|
|
|
|
return false;
|
|
|
|
TI = TypeIndexMap[TI.toArrayIndex()];
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-10-25 01:02:40 +08:00
|
|
|
static void remapTypesInSymbolRecord(ObjFile *File, SymbolKind SymKind,
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
MutableArrayRef<uint8_t> RecordBytes,
|
2017-07-18 08:21:25 +08:00
|
|
|
const CVIndexMap &IndexMap,
|
2017-06-22 01:25:56 +08:00
|
|
|
ArrayRef<TiReference> TypeRefs) {
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
MutableArrayRef<uint8_t> Contents =
|
|
|
|
RecordBytes.drop_front(sizeof(RecordPrefix));
|
2017-06-22 01:25:56 +08:00
|
|
|
for (const TiReference &Ref : TypeRefs) {
|
|
|
|
unsigned ByteSize = Ref.Count * sizeof(TypeIndex);
|
2017-07-13 02:49:43 +08:00
|
|
|
if (Contents.size() < Ref.Offset + ByteSize)
|
|
|
|
fatal("symbol record too short");
|
2017-07-18 08:21:25 +08:00
|
|
|
|
|
|
|
// This can be an item index or a type index. Choose the appropriate map.
|
|
|
|
ArrayRef<TypeIndex> TypeOrItemMap = IndexMap.TPIMap;
|
2017-10-25 01:02:40 +08:00
|
|
|
bool IsItemIndex = Ref.Kind == TiRefKind::IndexRef;
|
|
|
|
if (IsItemIndex && IndexMap.IsTypeServerMap)
|
2017-07-18 08:21:25 +08:00
|
|
|
TypeOrItemMap = IndexMap.IPIMap;
|
|
|
|
|
2017-06-22 01:25:56 +08:00
|
|
|
MutableArrayRef<TypeIndex> TIs(
|
|
|
|
reinterpret_cast<TypeIndex *>(Contents.data() + Ref.Offset), Ref.Count);
|
2017-07-13 02:49:43 +08:00
|
|
|
for (TypeIndex &TI : TIs) {
|
2017-07-18 08:21:25 +08:00
|
|
|
if (!remapTypeIndex(TI, TypeOrItemMap)) {
|
2017-10-25 01:02:40 +08:00
|
|
|
log("ignoring symbol record of kind 0x" + utohexstr(SymKind) + " in " +
|
|
|
|
File->getName() + " with bad " + (IsItemIndex ? "item" : "type") +
|
|
|
|
" index 0x" + utohexstr(TI.getIndex()));
|
2017-10-24 06:44:51 +08:00
|
|
|
TI = TypeIndex(SimpleTypeKind::NotTranslated);
|
2017-07-13 02:49:43 +08:00
|
|
|
continue;
|
2017-06-22 01:25:56 +08:00
|
|
|
}
|
2017-07-13 02:49:43 +08:00
|
|
|
}
|
2017-06-22 01:25:56 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-01-06 03:12:40 +08:00
|
|
|
static void
|
|
|
|
recordStringTableReferenceAtOffset(MutableArrayRef<uint8_t> Contents,
|
|
|
|
uint32_t Offset,
|
|
|
|
std::vector<ulittle32_t *> &StrTableRefs) {
|
|
|
|
Contents =
|
|
|
|
Contents.drop_front(Offset).take_front(sizeof(support::ulittle32_t));
|
|
|
|
ulittle32_t *Index = reinterpret_cast<ulittle32_t *>(Contents.data());
|
|
|
|
StrTableRefs.push_back(Index);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
recordStringTableReferences(SymbolKind Kind, MutableArrayRef<uint8_t> Contents,
|
|
|
|
std::vector<ulittle32_t *> &StrTableRefs) {
|
|
|
|
// For now we only handle S_FILESTATIC, but we may need the same logic for
|
|
|
|
// S_DEFRANGE and S_DEFRANGE_SUBFIELD. However, I cannot seem to generate any
|
|
|
|
// PDBs that contain these types of records, so because of the uncertainty
|
|
|
|
// they are omitted here until we can prove that it's necessary.
|
|
|
|
switch (Kind) {
|
|
|
|
case SymbolKind::S_FILESTATIC:
|
|
|
|
// FileStaticSym::ModFileOffset
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
recordStringTableReferenceAtOffset(Contents, 8, StrTableRefs);
|
2018-01-06 03:12:40 +08:00
|
|
|
break;
|
|
|
|
case SymbolKind::S_DEFRANGE:
|
|
|
|
case SymbolKind::S_DEFRANGE_SUBFIELD:
|
|
|
|
log("Not fixing up string table reference in S_DEFRANGE / "
|
|
|
|
"S_DEFRANGE_SUBFIELD record");
|
|
|
|
break;
|
2018-01-06 03:28:39 +08:00
|
|
|
default:
|
|
|
|
break;
|
2018-01-06 03:12:40 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-08-09 02:34:44 +08:00
|
|
|
static SymbolKind symbolKind(ArrayRef<uint8_t> RecordData) {
|
|
|
|
const RecordPrefix *Prefix =
|
|
|
|
reinterpret_cast<const RecordPrefix *>(RecordData.data());
|
|
|
|
return static_cast<SymbolKind>(uint16_t(Prefix->RecordKind));
|
|
|
|
}
|
|
|
|
|
|
|
|
/// MSVC translates S_PROC_ID_END to S_END, and S_[LG]PROC32_ID to S_[LG]PROC32
|
|
|
|
static void translateIdSymbols(MutableArrayRef<uint8_t> &RecordData,
|
2017-11-30 03:35:21 +08:00
|
|
|
TypeCollection &IDTable) {
|
2017-08-09 02:34:44 +08:00
|
|
|
RecordPrefix *Prefix = reinterpret_cast<RecordPrefix *>(RecordData.data());
|
|
|
|
|
|
|
|
SymbolKind Kind = symbolKind(RecordData);
|
|
|
|
|
|
|
|
if (Kind == SymbolKind::S_PROC_ID_END) {
|
|
|
|
Prefix->RecordKind = SymbolKind::S_END;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// In an object file, GPROC32_ID has an embedded reference which refers to the
|
|
|
|
// single object file type index namespace. This has already been translated
|
|
|
|
// to the PDB file's ID stream index space, but we need to convert this to a
|
|
|
|
// symbol that refers to the type stream index space. So we remap again from
|
|
|
|
// ID index space to type index space.
|
|
|
|
if (Kind == SymbolKind::S_GPROC32_ID || Kind == SymbolKind::S_LPROC32_ID) {
|
|
|
|
SmallVector<TiReference, 1> Refs;
|
|
|
|
auto Content = RecordData.drop_front(sizeof(RecordPrefix));
|
2019-04-04 08:28:48 +08:00
|
|
|
CVSymbol Sym(RecordData);
|
2017-08-09 02:34:44 +08:00
|
|
|
discoverTypeIndicesInSymbol(Sym, Refs);
|
|
|
|
assert(Refs.size() == 1);
|
|
|
|
assert(Refs.front().Count == 1);
|
|
|
|
|
|
|
|
TypeIndex *TI =
|
|
|
|
reinterpret_cast<TypeIndex *>(Content.data() + Refs[0].Offset);
|
|
|
|
// `TI` is the index of a FuncIdRecord or MemberFuncIdRecord which lives in
|
|
|
|
// the IPI stream, whose `FunctionType` member refers to the TPI stream.
|
|
|
|
// Note that LF_FUNC_ID and LF_MEMFUNC_ID have the same record layout, and
|
|
|
|
// in both cases we just need the second type index.
|
|
|
|
if (!TI->isSimple() && !TI->isNoneType()) {
|
2017-11-30 03:35:21 +08:00
|
|
|
CVType FuncIdData = IDTable.getType(*TI);
|
2017-08-09 02:34:44 +08:00
|
|
|
SmallVector<TypeIndex, 2> Indices;
|
|
|
|
discoverTypeIndices(FuncIdData, Indices);
|
|
|
|
assert(Indices.size() == 2);
|
|
|
|
*TI = Indices[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
Kind = (Kind == SymbolKind::S_GPROC32_ID) ? SymbolKind::S_GPROC32
|
|
|
|
: SymbolKind::S_LPROC32;
|
|
|
|
Prefix->RecordKind = uint16_t(Kind);
|
|
|
|
}
|
2017-06-22 01:25:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Copy the symbol record. In a PDB, symbol records must be 4 byte aligned.
|
|
|
|
/// The object file may not be aligned.
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
static MutableArrayRef<uint8_t>
|
|
|
|
copyAndAlignSymbol(const CVSymbol &Sym, MutableArrayRef<uint8_t> &AlignedMem) {
|
2017-06-22 01:25:56 +08:00
|
|
|
size_t Size = alignTo(Sym.length(), alignOf(CodeViewContainer::Pdb));
|
|
|
|
assert(Size >= 4 && "record too short");
|
|
|
|
assert(Size <= MaxRecordLength && "record too long");
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
assert(AlignedMem.size() >= Size && "didn't preallocate enough");
|
2017-06-22 01:25:56 +08:00
|
|
|
|
|
|
|
// Copy the symbol record and zero out any padding bytes.
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
MutableArrayRef<uint8_t> NewData = AlignedMem.take_front(Size);
|
|
|
|
AlignedMem = AlignedMem.drop_front(Size);
|
2017-06-22 01:25:56 +08:00
|
|
|
memcpy(NewData.data(), Sym.data().data(), Sym.length());
|
|
|
|
memset(NewData.data() + Sym.length(), 0, Size - Sym.length());
|
|
|
|
|
|
|
|
// Update the record prefix length. It should point to the beginning of the
|
2017-08-09 02:34:44 +08:00
|
|
|
// next record.
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
auto *Prefix = reinterpret_cast<RecordPrefix *>(NewData.data());
|
2017-06-22 01:25:56 +08:00
|
|
|
Prefix->RecordLen = Size - 2;
|
|
|
|
return NewData;
|
|
|
|
}
|
|
|
|
|
2017-07-07 00:39:32 +08:00
|
|
|
struct ScopeRecord {
|
|
|
|
ulittle32_t PtrParent;
|
|
|
|
ulittle32_t PtrEnd;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct SymbolScope {
|
|
|
|
ScopeRecord *OpeningRecord;
|
|
|
|
uint32_t ScopeOffset;
|
|
|
|
};
|
|
|
|
|
|
|
|
static void scopeStackOpen(SmallVectorImpl<SymbolScope> &Stack,
|
|
|
|
uint32_t CurOffset, CVSymbol &Sym) {
|
|
|
|
assert(symbolOpensScope(Sym.kind()));
|
|
|
|
SymbolScope S;
|
|
|
|
S.ScopeOffset = CurOffset;
|
|
|
|
S.OpeningRecord = const_cast<ScopeRecord *>(
|
|
|
|
reinterpret_cast<const ScopeRecord *>(Sym.content().data()));
|
|
|
|
S.OpeningRecord->PtrParent = Stack.empty() ? 0 : Stack.back().ScopeOffset;
|
|
|
|
Stack.push_back(S);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void scopeStackClose(SmallVectorImpl<SymbolScope> &Stack,
|
2019-03-30 04:25:34 +08:00
|
|
|
uint32_t CurOffset, InputFile *File) {
|
2017-07-07 00:39:32 +08:00
|
|
|
if (Stack.empty()) {
|
|
|
|
warn("symbol scopes are not balanced in " + File->getName());
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
SymbolScope S = Stack.pop_back_val();
|
|
|
|
S.OpeningRecord->PtrEnd = CurOffset;
|
|
|
|
}
|
|
|
|
|
2018-12-05 05:48:46 +08:00
|
|
|
static bool symbolGoesInModuleStream(const CVSymbol &Sym, bool IsGlobalScope) {
|
2017-08-12 03:00:03 +08:00
|
|
|
switch (Sym.kind()) {
|
|
|
|
case SymbolKind::S_GDATA32:
|
|
|
|
case SymbolKind::S_CONSTANT:
|
|
|
|
// We really should not be seeing S_PROCREF and S_LPROCREF in the first place
|
|
|
|
// since they are synthesized by the linker in response to S_GPROC32 and
|
|
|
|
// S_LPROC32, but if we do see them, don't put them in the module stream I
|
|
|
|
// guess.
|
|
|
|
case SymbolKind::S_PROCREF:
|
|
|
|
case SymbolKind::S_LPROCREF:
|
|
|
|
return false;
|
2018-12-05 05:48:46 +08:00
|
|
|
// S_UDT records go in the module stream if it is not a global S_UDT.
|
|
|
|
case SymbolKind::S_UDT:
|
|
|
|
return !IsGlobalScope;
|
2017-08-12 03:00:03 +08:00
|
|
|
// S_GDATA32 does not go in the module stream, but S_LDATA32 does.
|
|
|
|
case SymbolKind::S_LDATA32:
|
|
|
|
default:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-05 05:48:46 +08:00
|
|
|
static bool symbolGoesInGlobalsStream(const CVSymbol &Sym, bool IsGlobalScope) {
|
2017-08-12 03:00:03 +08:00
|
|
|
switch (Sym.kind()) {
|
|
|
|
case SymbolKind::S_CONSTANT:
|
|
|
|
case SymbolKind::S_GDATA32:
|
|
|
|
// S_LDATA32 goes in both the module stream and the globals stream.
|
|
|
|
case SymbolKind::S_LDATA32:
|
|
|
|
case SymbolKind::S_GPROC32:
|
|
|
|
case SymbolKind::S_LPROC32:
|
|
|
|
// We really should not be seeing S_PROCREF and S_LPROCREF in the first place
|
|
|
|
// since they are synthesized by the linker in response to S_GPROC32 and
|
|
|
|
// S_LPROC32, but if we do see them, copy them straight through.
|
|
|
|
case SymbolKind::S_PROCREF:
|
|
|
|
case SymbolKind::S_LPROCREF:
|
|
|
|
return true;
|
2018-12-05 05:48:46 +08:00
|
|
|
// S_UDT records go in the globals stream if it is a global S_UDT.
|
2017-08-15 02:44:58 +08:00
|
|
|
case SymbolKind::S_UDT:
|
2018-12-05 05:48:46 +08:00
|
|
|
return IsGlobalScope;
|
2017-08-12 03:00:03 +08:00
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
static void addGlobalSymbol(pdb::GSIStreamBuilder &Builder, uint16_t ModIndex,
|
|
|
|
unsigned SymOffset, const CVSymbol &Sym) {
|
2017-08-12 03:00:03 +08:00
|
|
|
switch (Sym.kind()) {
|
|
|
|
case SymbolKind::S_CONSTANT:
|
|
|
|
case SymbolKind::S_UDT:
|
|
|
|
case SymbolKind::S_GDATA32:
|
|
|
|
case SymbolKind::S_LDATA32:
|
|
|
|
case SymbolKind::S_PROCREF:
|
|
|
|
case SymbolKind::S_LPROCREF:
|
|
|
|
Builder.addGlobalSymbol(Sym);
|
|
|
|
break;
|
|
|
|
case SymbolKind::S_GPROC32:
|
|
|
|
case SymbolKind::S_LPROC32: {
|
|
|
|
SymbolRecordKind K = SymbolRecordKind::ProcRefSym;
|
|
|
|
if (Sym.kind() == SymbolKind::S_LPROC32)
|
|
|
|
K = SymbolRecordKind::LocalProcRef;
|
|
|
|
ProcRefSym PS(K);
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
PS.Module = ModIndex;
|
2017-08-12 03:00:03 +08:00
|
|
|
// For some reason, MSVC seems to add one to this value.
|
|
|
|
++PS.Module;
|
|
|
|
PS.Name = getSymbolName(Sym);
|
|
|
|
PS.SumName = 0;
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
PS.SymOffset = SymOffset;
|
2017-08-12 03:00:03 +08:00
|
|
|
Builder.addGlobalSymbol(PS);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Invalid symbol kind!");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-11-14 07:44:39 +08:00
|
|
|
void PDBLinker::mergeSymbolRecords(ObjFile *File, const CVIndexMap &IndexMap,
|
|
|
|
std::vector<ulittle32_t *> &StringTableRefs,
|
|
|
|
BinaryStreamRef SymData) {
|
2018-01-19 02:35:01 +08:00
|
|
|
ArrayRef<uint8_t> SymsBuffer;
|
|
|
|
cantFail(SymData.readBytes(0, SymData.getLength(), SymsBuffer));
|
2017-07-07 00:39:32 +08:00
|
|
|
SmallVector<SymbolScope, 4> Scopes;
|
2018-01-06 03:12:40 +08:00
|
|
|
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
// Iterate every symbol to check if any need to be realigned, and if so, how
|
|
|
|
// much space we need to allocate for them.
|
|
|
|
bool NeedsRealignment = false;
|
2018-12-18 09:14:05 +08:00
|
|
|
unsigned TotalRealignedSize = 0;
|
2018-01-19 02:35:01 +08:00
|
|
|
auto EC = forEachCodeViewRecord<CVSymbol>(
|
2018-11-14 07:44:39 +08:00
|
|
|
SymsBuffer, [&](CVSymbol Sym) -> llvm::Error {
|
2018-12-18 09:14:05 +08:00
|
|
|
unsigned RealignedSize =
|
|
|
|
alignTo(Sym.length(), alignOf(CodeViewContainer::Pdb));
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
NeedsRealignment |= RealignedSize != Sym.length();
|
2018-12-18 09:14:05 +08:00
|
|
|
TotalRealignedSize += RealignedSize;
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
return Error::success();
|
|
|
|
});
|
|
|
|
|
|
|
|
// If any of the symbol record lengths was corrupt, ignore them all, warn
|
|
|
|
// about it, and move on.
|
|
|
|
if (EC) {
|
|
|
|
warn("corrupt symbol records in " + File->getName());
|
|
|
|
consumeError(std::move(EC));
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If any symbol needed realignment, allocate enough contiguous memory for
|
|
|
|
// them all. Typically symbol subsections are small enough that this will not
|
|
|
|
// cause fragmentation.
|
|
|
|
MutableArrayRef<uint8_t> AlignedSymbolMem;
|
|
|
|
if (NeedsRealignment) {
|
|
|
|
void *AlignedData =
|
2018-12-18 09:14:05 +08:00
|
|
|
Alloc.Allocate(TotalRealignedSize, alignOf(CodeViewContainer::Pdb));
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
AlignedSymbolMem = makeMutableArrayRef(
|
2018-12-18 09:14:05 +08:00
|
|
|
reinterpret_cast<uint8_t *>(AlignedData), TotalRealignedSize);
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Iterate again, this time doing the real work.
|
|
|
|
unsigned CurSymOffset = File->ModuleDBI->getNextSymbolOffset();
|
|
|
|
ArrayRef<uint8_t> BulkSymbols;
|
|
|
|
cantFail(forEachCodeViewRecord<CVSymbol>(
|
|
|
|
SymsBuffer, [&](CVSymbol Sym) -> llvm::Error {
|
|
|
|
// Align the record if required.
|
|
|
|
MutableArrayRef<uint8_t> RecordBytes;
|
|
|
|
if (NeedsRealignment) {
|
|
|
|
RecordBytes = copyAndAlignSymbol(Sym, AlignedSymbolMem);
|
2019-04-04 08:28:48 +08:00
|
|
|
Sym = CVSymbol(RecordBytes);
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
} else {
|
|
|
|
// Otherwise, we can actually mutate the symbol directly, since we
|
|
|
|
// copied it to apply relocations.
|
|
|
|
RecordBytes = makeMutableArrayRef(
|
|
|
|
const_cast<uint8_t *>(Sym.data().data()), Sym.length());
|
|
|
|
}
|
|
|
|
|
2018-01-19 02:35:01 +08:00
|
|
|
// Discover type index references in the record. Skip it if we don't
|
|
|
|
// know where they are.
|
|
|
|
SmallVector<TiReference, 32> TypeRefs;
|
|
|
|
if (!discoverTypeIndicesInSymbol(Sym, TypeRefs)) {
|
|
|
|
log("ignoring unknown symbol record with kind 0x" +
|
|
|
|
utohexstr(Sym.kind()));
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Re-map all the type index references.
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
remapTypesInSymbolRecord(File, Sym.kind(), RecordBytes, IndexMap,
|
2018-01-19 02:35:01 +08:00
|
|
|
TypeRefs);
|
|
|
|
|
|
|
|
// An object file may have S_xxx_ID symbols, but these get converted to
|
|
|
|
// "real" symbols in a PDB.
|
2019-04-03 04:43:19 +08:00
|
|
|
translateIdSymbols(RecordBytes, TMerger.getIDTable());
|
2019-04-04 08:28:48 +08:00
|
|
|
Sym = CVSymbol(RecordBytes);
|
2018-01-19 02:35:01 +08:00
|
|
|
|
|
|
|
// If this record refers to an offset in the object file's string table,
|
|
|
|
// add that item to the global PDB string table and re-write the index.
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
recordStringTableReferences(Sym.kind(), RecordBytes, StringTableRefs);
|
2018-01-19 02:35:01 +08:00
|
|
|
|
|
|
|
// Fill in "Parent" and "End" fields by maintaining a stack of scopes.
|
2018-11-14 07:44:39 +08:00
|
|
|
if (symbolOpensScope(Sym.kind()))
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
scopeStackOpen(Scopes, CurSymOffset, Sym);
|
2018-11-14 07:44:39 +08:00
|
|
|
else if (symbolEndsScope(Sym.kind()))
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
scopeStackClose(Scopes, CurSymOffset, File);
|
2018-01-19 02:35:01 +08:00
|
|
|
|
|
|
|
// Add the symbol to the globals stream if necessary. Do this before
|
|
|
|
// adding the symbol to the module since we may need to get the next
|
|
|
|
// symbol offset, and writing to the module's symbol stream will update
|
|
|
|
// that offset.
|
2019-03-15 02:45:08 +08:00
|
|
|
if (symbolGoesInGlobalsStream(Sym, Scopes.empty())) {
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
addGlobalSymbol(Builder.getGsiBuilder(),
|
|
|
|
File->ModuleDBI->getModuleIndex(), CurSymOffset, Sym);
|
2019-03-15 02:45:08 +08:00
|
|
|
++GlobalSymbols;
|
|
|
|
}
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
|
2018-12-05 05:48:46 +08:00
|
|
|
if (symbolGoesInModuleStream(Sym, Scopes.empty())) {
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
// Add symbols to the module in bulk. If this symbol is contiguous
|
|
|
|
// with the previous run of symbols to add, combine the ranges. If
|
|
|
|
// not, close the previous range of symbols and start a new one.
|
|
|
|
if (Sym.data().data() == BulkSymbols.end()) {
|
|
|
|
BulkSymbols = makeArrayRef(BulkSymbols.data(),
|
|
|
|
BulkSymbols.size() + Sym.length());
|
|
|
|
} else {
|
|
|
|
File->ModuleDBI->addSymbolsInBulk(BulkSymbols);
|
|
|
|
BulkSymbols = RecordBytes;
|
|
|
|
}
|
|
|
|
CurSymOffset += Sym.length();
|
2019-03-15 02:45:08 +08:00
|
|
|
++ModuleSymbols;
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
}
|
2018-01-19 02:35:01 +08:00
|
|
|
return Error::success();
|
[PDB] Add symbol records in bulk
Summary:
This speeds up linking clang.exe/pdb with /DEBUG:GHASH by 31%, from
12.9s to 9.8s.
Symbol records are typically small (16.7 bytes on average), but we
processed them one at a time. CVSymbol is a relatively "large" type. It
wraps an ArrayRef<uint8_t> with a kind an optional 32-bit hash, which we
don't need. Before this change, each DbiModuleDescriptorBuilder would
maintain an array of CVSymbols, and would write them individually with a
BinaryItemStream.
With this change, we now add symbols that happen to appear contiguously
in bulk. For each .debug$S section (roughly one per function), we
allocate two copies, one for relocation, and one for realignment
purposes. For runs of symbols that go in the module stream, which is
most symbols, we now add them as a single ArrayRef<uint8_t>, so the
vector DbiModuleDescriptorBuilder is roughly linear in the number of
.debug$S sections (O(# funcs)) instead of the number of symbol records
(very large).
Some stats on symbol sizes for the curious:
PDB size: 507M
sym bytes: 316,508,016
sym count: 18,954,971
sym byte avg: 16.7
As future work, we may be able to skip copying symbol records in the
linker for realignment purposes if we make LLVM write them aligned into
the object file. We need to double check that such symbol records are
still compatible with link.exe, but if so, it's definitely worth doing,
since my profile shows we spend 500ms in memcpy in the symbol merging
code. We could potentially cut that in half by saving a copy.
Alternatively, we could apply the relocations *after* we iterate the
symbols. This would require some careful re-engineering of the
relocation processing code, though.
Reviewers: zturner, aganea, ruiu
Subscribers: hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D54554
llvm-svn: 347687
2018-11-28 03:00:23 +08:00
|
|
|
}));
|
|
|
|
|
|
|
|
// Add any remaining symbols we've accumulated.
|
|
|
|
File->ModuleDBI->addSymbolsInBulk(BulkSymbols);
|
2017-06-22 01:25:56 +08:00
|
|
|
}
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
// Allocate memory for a .debug$S / .debug$F section and relocate it.
|
2017-06-20 01:21:45 +08:00
|
|
|
static ArrayRef<uint8_t> relocateDebugChunk(BumpPtrAllocator &Alloc,
|
2018-09-13 05:02:01 +08:00
|
|
|
SectionChunk &DebugChunk) {
|
|
|
|
uint8_t *Buffer = Alloc.Allocate<uint8_t>(DebugChunk.getSize());
|
2019-05-25 02:25:49 +08:00
|
|
|
assert(DebugChunk.getOutputSectionIdx() == 0 &&
|
2017-06-20 01:21:45 +08:00
|
|
|
"debug sections should not be in output sections");
|
2018-09-13 05:02:01 +08:00
|
|
|
DebugChunk.writeTo(Buffer);
|
|
|
|
return makeArrayRef(Buffer, DebugChunk.getSize());
|
2017-06-20 01:21:45 +08:00
|
|
|
}
|
|
|
|
|
2018-04-21 02:00:46 +08:00
|
|
|
static pdb::SectionContrib createSectionContrib(const Chunk *C, uint32_t Modi) {
|
2019-03-19 03:13:23 +08:00
|
|
|
OutputSection *OS = C ? C->getOutputSection() : nullptr;
|
2018-04-21 02:00:46 +08:00
|
|
|
pdb::SectionContrib SC;
|
|
|
|
memset(&SC, 0, sizeof(SC));
|
2019-03-19 03:13:23 +08:00
|
|
|
SC.ISect = OS ? OS->SectionIndex : llvm::pdb::kInvalidStreamIndex;
|
|
|
|
SC.Off = C && OS ? C->getRVA() - OS->getRVA() : 0;
|
|
|
|
SC.Size = C ? C->getSize() : -1;
|
|
|
|
if (auto *SecChunk = dyn_cast_or_null<SectionChunk>(C)) {
|
2018-04-21 02:00:46 +08:00
|
|
|
SC.Characteristics = SecChunk->Header->Characteristics;
|
|
|
|
SC.Imod = SecChunk->File->ModuleDBI->getModuleIndex();
|
|
|
|
ArrayRef<uint8_t> Contents = SecChunk->getContents();
|
|
|
|
JamCRC CRC(0);
|
|
|
|
ArrayRef<char> CharContents = makeArrayRef(
|
|
|
|
reinterpret_cast<const char *>(Contents.data()), Contents.size());
|
|
|
|
CRC.update(CharContents);
|
|
|
|
SC.DataCrc = CRC.getCRC();
|
|
|
|
} else {
|
2019-03-19 03:13:23 +08:00
|
|
|
SC.Characteristics = OS ? OS->Header.Characteristics : 0;
|
2018-04-21 02:00:46 +08:00
|
|
|
SC.Imod = Modi;
|
|
|
|
}
|
|
|
|
SC.RelocCrc = 0; // FIXME
|
|
|
|
|
|
|
|
return SC;
|
|
|
|
}
|
|
|
|
|
2018-09-12 06:35:01 +08:00
|
|
|
static uint32_t
|
|
|
|
translateStringTableIndex(uint32_t ObjIndex,
|
|
|
|
const DebugStringTableSubsectionRef &ObjStrTable,
|
|
|
|
DebugStringTableSubsection &PdbStrTable) {
|
|
|
|
auto ExpectedString = ObjStrTable.getString(ObjIndex);
|
|
|
|
if (!ExpectedString) {
|
|
|
|
warn("Invalid string table reference");
|
|
|
|
consumeError(ExpectedString.takeError());
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return PdbStrTable.insert(*ExpectedString);
|
|
|
|
}
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
void DebugSHandler::handleDebugS(lld::coff::SectionChunk &DebugS) {
|
|
|
|
DebugSubsectionArray Subsections;
|
|
|
|
|
2019-02-23 09:46:18 +08:00
|
|
|
ArrayRef<uint8_t> RelocatedDebugContents = SectionChunk::consumeDebugMagic(
|
2018-09-13 05:02:01 +08:00
|
|
|
relocateDebugChunk(Linker.Alloc, DebugS), DebugS.getSectionName());
|
|
|
|
|
|
|
|
BinaryStreamReader Reader(RelocatedDebugContents, support::little);
|
|
|
|
ExitOnErr(Reader.readArray(Subsections, RelocatedDebugContents.size()));
|
|
|
|
|
|
|
|
for (const DebugSubsectionRecord &SS : Subsections) {
|
|
|
|
switch (SS.kind()) {
|
|
|
|
case DebugSubsectionKind::StringTable: {
|
|
|
|
assert(!CVStrTab.valid() &&
|
|
|
|
"Encountered multiple string table subsections!");
|
|
|
|
ExitOnErr(CVStrTab.initialize(SS.getRecordData()));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case DebugSubsectionKind::FileChecksums:
|
|
|
|
assert(!Checksums.valid() &&
|
|
|
|
"Encountered multiple checksum subsections!");
|
|
|
|
ExitOnErr(Checksums.initialize(SS.getRecordData()));
|
|
|
|
break;
|
|
|
|
case DebugSubsectionKind::Lines:
|
|
|
|
// We can add the relocated line table directly to the PDB without
|
|
|
|
// modification because the file checksum offsets will stay the same.
|
|
|
|
File.ModuleDBI->addDebugSubsection(SS);
|
|
|
|
break;
|
2019-06-04 02:15:38 +08:00
|
|
|
case DebugSubsectionKind::InlineeLines:
|
|
|
|
assert(!InlineeLines.valid() &&
|
|
|
|
"Encountered multiple inlinee lines subsections!");
|
|
|
|
ExitOnErr(InlineeLines.initialize(SS.getRecordData()));
|
|
|
|
break;
|
2018-09-13 05:02:01 +08:00
|
|
|
case DebugSubsectionKind::FrameData: {
|
|
|
|
// We need to re-write string table indices here, so save off all
|
|
|
|
// frame data subsections until we've processed the entire list of
|
|
|
|
// subsections so that we can be sure we have the string table.
|
|
|
|
DebugFrameDataSubsectionRef FDS;
|
|
|
|
ExitOnErr(FDS.initialize(SS.getRecordData()));
|
|
|
|
NewFpoFrames.push_back(std::move(FDS));
|
|
|
|
break;
|
|
|
|
}
|
2018-11-10 09:36:02 +08:00
|
|
|
case DebugSubsectionKind::Symbols: {
|
2018-11-14 07:44:39 +08:00
|
|
|
Linker.mergeSymbolRecords(&File, IndexMap, StringTableReferences,
|
|
|
|
SS.getRecordData());
|
2018-09-13 05:02:01 +08:00
|
|
|
break;
|
2018-11-10 09:36:02 +08:00
|
|
|
}
|
2019-06-04 02:15:38 +08:00
|
|
|
|
|
|
|
case DebugSubsectionKind::CrossScopeImports:
|
|
|
|
case DebugSubsectionKind::CrossScopeExports:
|
|
|
|
// These appear to relate to cross-module optimization, so we might use
|
|
|
|
// these for ThinLTO.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DebugSubsectionKind::ILLines:
|
|
|
|
case DebugSubsectionKind::FuncMDTokenMap:
|
|
|
|
case DebugSubsectionKind::TypeMDTokenMap:
|
|
|
|
case DebugSubsectionKind::MergedAssemblyInput:
|
|
|
|
// These appear to relate to .Net assembly info.
|
|
|
|
break;
|
|
|
|
|
|
|
|
case DebugSubsectionKind::CoffSymbolRVA:
|
|
|
|
// Unclear what this is for.
|
|
|
|
break;
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
default:
|
2019-06-04 02:15:38 +08:00
|
|
|
warn("ignoring unknown debug$S subsection kind 0x" +
|
|
|
|
utohexstr(uint32_t(SS.kind())));
|
2018-09-13 05:02:01 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-04 02:15:38 +08:00
|
|
|
static Expected<StringRef>
|
|
|
|
getFileName(const DebugStringTableSubsectionRef &Strings,
|
|
|
|
const DebugChecksumsSubsectionRef &Checksums, uint32_t FileID) {
|
|
|
|
auto Iter = Checksums.getArray().at(FileID);
|
|
|
|
if (Iter == Checksums.getArray().end())
|
|
|
|
return make_error<CodeViewError>(cv_error_code::no_records);
|
|
|
|
uint32_t Offset = Iter->FileNameOffset;
|
|
|
|
return Strings.getString(Offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::shared_ptr<DebugInlineeLinesSubsection>
|
|
|
|
DebugSHandler::mergeInlineeLines(DebugChecksumsSubsection *NewChecksums) {
|
|
|
|
auto NewInlineeLines = std::make_shared<DebugInlineeLinesSubsection>(
|
|
|
|
*NewChecksums, InlineeLines.hasExtraFiles());
|
|
|
|
|
|
|
|
for (const InlineeSourceLine &Line : InlineeLines) {
|
|
|
|
TypeIndex Inlinee = Line.Header->Inlinee;
|
|
|
|
uint32_t FileID = Line.Header->FileID;
|
|
|
|
uint32_t SourceLine = Line.Header->SourceLineNum;
|
|
|
|
|
|
|
|
ArrayRef<TypeIndex> TypeOrItemMap =
|
|
|
|
IndexMap.IsTypeServerMap ? IndexMap.IPIMap : IndexMap.TPIMap;
|
|
|
|
if (!remapTypeIndex(Inlinee, TypeOrItemMap)) {
|
|
|
|
log("ignoring inlinee line record in " + File.getName() +
|
|
|
|
" with bad inlinee index 0x" + utohexstr(Inlinee.getIndex()));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallString<128> Filename =
|
|
|
|
ExitOnErr(getFileName(CVStrTab, Checksums, FileID));
|
|
|
|
pdbMakeAbsolute(Filename);
|
|
|
|
NewInlineeLines->addInlineSite(Inlinee, Filename, SourceLine);
|
|
|
|
|
|
|
|
if (InlineeLines.hasExtraFiles()) {
|
|
|
|
for (uint32_t ExtraFileId : Line.ExtraFiles) {
|
|
|
|
Filename = ExitOnErr(getFileName(CVStrTab, Checksums, ExtraFileId));
|
|
|
|
pdbMakeAbsolute(Filename);
|
|
|
|
NewInlineeLines->addExtraFile(Filename);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return NewInlineeLines;
|
|
|
|
}
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
void DebugSHandler::finish() {
|
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Linker.Builder.getDbiBuilder();
|
|
|
|
|
|
|
|
// We should have seen all debug subsections across the entire object file now
|
|
|
|
// which means that if a StringTable subsection and Checksums subsection were
|
|
|
|
// present, now is the time to handle them.
|
|
|
|
if (!CVStrTab.valid()) {
|
|
|
|
if (Checksums.valid())
|
|
|
|
fatal(".debug$S sections with a checksums subsection must also contain a "
|
|
|
|
"string table subsection");
|
|
|
|
|
|
|
|
if (!StringTableReferences.empty())
|
|
|
|
warn("No StringTable subsection was encountered, but there are string "
|
|
|
|
"table references");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Rewrite string table indices in the Fpo Data and symbol records to refer to
|
|
|
|
// the global PDB string table instead of the object file string table.
|
|
|
|
for (DebugFrameDataSubsectionRef &FDS : NewFpoFrames) {
|
2018-11-21 05:30:11 +08:00
|
|
|
const ulittle32_t *Reloc = FDS.getRelocPtr();
|
2018-09-13 05:02:01 +08:00
|
|
|
for (codeview::FrameData FD : FDS) {
|
|
|
|
FD.RvaStart += *Reloc;
|
|
|
|
FD.FrameFunc =
|
|
|
|
translateStringTableIndex(FD.FrameFunc, CVStrTab, Linker.PDBStrTab);
|
|
|
|
DbiBuilder.addNewFpoData(FD);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
for (ulittle32_t *Ref : StringTableReferences)
|
|
|
|
*Ref = translateStringTableIndex(*Ref, CVStrTab, Linker.PDBStrTab);
|
|
|
|
|
|
|
|
// Make a new file checksum table that refers to offsets in the PDB-wide
|
|
|
|
// string table. Generally the string table subsection appears after the
|
|
|
|
// checksum table, so we have to do this after looping over all the
|
|
|
|
// subsections.
|
|
|
|
auto NewChecksums = make_unique<DebugChecksumsSubsection>(Linker.PDBStrTab);
|
|
|
|
for (FileChecksumEntry &FC : Checksums) {
|
2019-06-04 02:15:38 +08:00
|
|
|
SmallString<128> Filename =
|
2018-09-13 05:02:01 +08:00
|
|
|
ExitOnErr(CVStrTab.getString(FC.FileNameOffset));
|
2019-06-04 02:15:38 +08:00
|
|
|
pdbMakeAbsolute(Filename);
|
|
|
|
ExitOnErr(DbiBuilder.addModuleSourceFile(*File.ModuleDBI, Filename));
|
|
|
|
NewChecksums->addChecksum(Filename, FC.Kind, FC.Checksum);
|
2018-09-13 05:02:01 +08:00
|
|
|
}
|
2019-06-04 02:15:38 +08:00
|
|
|
|
|
|
|
// Rewrite inlinee item indices if present.
|
|
|
|
if (InlineeLines.valid())
|
|
|
|
File.ModuleDBI->addDebugSubsection(mergeInlineeLines(NewChecksums.get()));
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
File.ModuleDBI->addDebugSubsection(std::move(NewChecksums));
|
|
|
|
}
|
|
|
|
|
2018-11-06 03:20:47 +08:00
|
|
|
void PDBLinker::addObjFile(ObjFile *File, CVIndexMap *ExternIndexMap) {
|
2019-03-23 06:07:27 +08:00
|
|
|
if (File->MergedIntoPDB)
|
2018-11-06 03:20:47 +08:00
|
|
|
return;
|
2019-03-23 06:07:27 +08:00
|
|
|
File->MergedIntoPDB = true;
|
2018-04-21 02:00:46 +08:00
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
// Before we can process symbol substreams from .debug$S, we need to process
|
|
|
|
// type information, file checksums, and the string table. Add type info to
|
|
|
|
// the PDB first, so that we can get the map from object file type and item
|
|
|
|
// indices to PDB type and item indices.
|
2017-07-18 08:21:25 +08:00
|
|
|
CVIndexMap ObjectIndexMap;
|
2018-11-06 03:20:47 +08:00
|
|
|
auto IndexMapResult =
|
|
|
|
mergeDebugT(File, ExternIndexMap ? ExternIndexMap : &ObjectIndexMap);
|
2018-02-01 01:48:04 +08:00
|
|
|
|
|
|
|
// If the .debug$T sections fail to merge, assume there is no debug info.
|
|
|
|
if (!IndexMapResult) {
|
2019-01-12 04:39:38 +08:00
|
|
|
if (!Config->WarnDebugInfoUnusable) {
|
|
|
|
consumeError(IndexMapResult.takeError());
|
2019-01-12 03:10:01 +08:00
|
|
|
return;
|
2019-01-12 04:39:38 +08:00
|
|
|
}
|
2019-03-23 06:07:27 +08:00
|
|
|
warn("Cannot use debug info for '" + toString(File) + "' [LNK4099]\n" +
|
2018-09-10 21:51:21 +08:00
|
|
|
">>> failed to load reference " +
|
|
|
|
StringRef(toString(IndexMapResult.takeError())));
|
2018-02-01 01:48:04 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T(SymbolMergingTimer);
|
|
|
|
|
2019-03-23 06:07:27 +08:00
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Builder.getDbiBuilder();
|
2018-09-13 05:02:01 +08:00
|
|
|
DebugSHandler DSH(*this, *File, *IndexMapResult);
|
|
|
|
// Now do all live .debug$S and .debug$F sections.
|
2017-07-14 08:14:58 +08:00
|
|
|
for (SectionChunk *DebugChunk : File->getDebugChunks()) {
|
2018-09-13 05:02:01 +08:00
|
|
|
if (!DebugChunk->Live || DebugChunk->getSize() == 0)
|
2017-07-14 08:14:58 +08:00
|
|
|
continue;
|
2017-06-20 01:21:45 +08:00
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
if (DebugChunk->getSectionName() == ".debug$S") {
|
|
|
|
DSH.handleDebugS(*DebugChunk);
|
2017-07-14 08:14:58 +08:00
|
|
|
continue;
|
|
|
|
}
|
2017-06-20 01:21:45 +08:00
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
if (DebugChunk->getSectionName() == ".debug$F") {
|
|
|
|
ArrayRef<uint8_t> RelocatedDebugContents =
|
|
|
|
relocateDebugChunk(Alloc, *DebugChunk);
|
2018-01-06 03:12:40 +08:00
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
FixedStreamArray<object::FpoData> FpoRecords;
|
|
|
|
BinaryStreamReader Reader(RelocatedDebugContents, support::little);
|
|
|
|
uint32_t Count = RelocatedDebugContents.size() / sizeof(object::FpoData);
|
|
|
|
ExitOnErr(Reader.readArray(FpoRecords, Count));
|
2018-01-06 03:12:40 +08:00
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
// These are already relocated and don't refer to the string table, so we
|
|
|
|
// can just copy it.
|
|
|
|
for (const object::FpoData &FD : FpoRecords)
|
|
|
|
DbiBuilder.addOldFpoData(FD);
|
|
|
|
continue;
|
2017-06-20 01:21:45 +08:00
|
|
|
}
|
2018-01-06 03:12:40 +08:00
|
|
|
}
|
|
|
|
|
2018-09-13 05:02:01 +08:00
|
|
|
// Do any post-processing now that all .debug$S sections have been processed.
|
|
|
|
DSH.finish();
|
2017-07-14 08:14:58 +08:00
|
|
|
}
|
2017-01-12 11:09:25 +08:00
|
|
|
|
2019-03-23 06:07:27 +08:00
|
|
|
// Add a module descriptor for every object file. We need to put an absolute
|
|
|
|
// path to the object into the PDB. If this is a plain object, we make its
|
|
|
|
// path absolute. If it's an object in an archive, we make the archive path
|
|
|
|
// absolute.
|
|
|
|
static void createModuleDBI(pdb::PDBFileBuilder &Builder) {
|
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Builder.getDbiBuilder();
|
|
|
|
SmallString<128> ObjName;
|
|
|
|
|
|
|
|
for (ObjFile *File : ObjFile::Instances) {
|
|
|
|
|
|
|
|
bool InArchive = !File->ParentName.empty();
|
|
|
|
ObjName = InArchive ? File->ParentName : File->getName();
|
|
|
|
pdbMakeAbsolute(ObjName);
|
|
|
|
StringRef ModName = InArchive ? File->getName() : StringRef(ObjName);
|
|
|
|
|
|
|
|
File->ModuleDBI = &ExitOnErr(DbiBuilder.addModuleInfo(ModName));
|
|
|
|
File->ModuleDBI->setObjFileName(ObjName);
|
|
|
|
|
|
|
|
ArrayRef<Chunk *> Chunks = File->getChunks();
|
|
|
|
uint32_t Modi = File->ModuleDBI->getModuleIndex();
|
|
|
|
|
|
|
|
for (Chunk *C : Chunks) {
|
|
|
|
auto *SecChunk = dyn_cast<SectionChunk>(C);
|
|
|
|
if (!SecChunk || !SecChunk->Live)
|
|
|
|
continue;
|
|
|
|
pdb::SectionContrib SC = createSectionContrib(SecChunk, Modi);
|
|
|
|
File->ModuleDBI->setFirstSectionContrib(SC);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-28 02:25:59 +08:00
|
|
|
static PublicSym32 createPublic(Defined *Def) {
|
|
|
|
PublicSym32 Pub(SymbolKind::S_PUB32);
|
|
|
|
Pub.Name = Def->getName();
|
|
|
|
if (auto *D = dyn_cast<DefinedCOFF>(Def)) {
|
|
|
|
if (D->getCOFFSymbol().isFunctionDefinition())
|
|
|
|
Pub.Flags = PublicSymFlags::Function;
|
|
|
|
} else if (isa<DefinedImportThunk>(Def)) {
|
|
|
|
Pub.Flags = PublicSymFlags::Function;
|
|
|
|
}
|
|
|
|
|
|
|
|
OutputSection *OS = Def->getChunk()->getOutputSection();
|
|
|
|
assert(OS && "all publics should be in final image");
|
|
|
|
Pub.Offset = Def->getRVA() - OS->getRVA();
|
|
|
|
Pub.Segment = OS->SectionIndex;
|
|
|
|
return Pub;
|
|
|
|
}
|
|
|
|
|
2017-07-14 08:14:58 +08:00
|
|
|
// Add all object files to the PDB. Merge .debug$T sections into IpiData and
|
|
|
|
// TpiData.
|
|
|
|
void PDBLinker::addObjectsToPDB() {
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T1(AddObjectsTimer);
|
2019-03-23 06:07:27 +08:00
|
|
|
|
|
|
|
createModuleDBI(Builder);
|
|
|
|
|
2017-07-27 08:45:26 +08:00
|
|
|
for (ObjFile *File : ObjFile::Instances)
|
2017-07-27 07:05:24 +08:00
|
|
|
addObjFile(File);
|
2017-07-14 08:14:58 +08:00
|
|
|
|
|
|
|
Builder.getStringTableBuilder().setStrings(PDBStrTab);
|
2018-01-18 03:16:26 +08:00
|
|
|
T1.stop();
|
2017-06-20 01:21:45 +08:00
|
|
|
|
2017-12-15 02:07:04 +08:00
|
|
|
// Construct TPI and IPI stream contents.
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T2(TpiStreamLayoutTimer);
|
2019-04-03 04:43:19 +08:00
|
|
|
addTypeInfo(Builder.getTpiBuilder(), TMerger.getTypeTable());
|
|
|
|
addTypeInfo(Builder.getIpiBuilder(), TMerger.getIDTable());
|
2018-01-18 03:16:26 +08:00
|
|
|
T2.stop();
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T3(GlobalsLayoutTimer);
|
2017-08-12 03:00:03 +08:00
|
|
|
// Compute the public and global symbols.
|
|
|
|
auto &GsiBuilder = Builder.getGsiBuilder();
|
2017-07-28 02:25:59 +08:00
|
|
|
std::vector<PublicSym32> Publics;
|
2017-11-04 05:21:47 +08:00
|
|
|
Symtab->forEachSymbol([&Publics](Symbol *S) {
|
2017-07-28 02:25:59 +08:00
|
|
|
// Only emit defined, live symbols that have a chunk.
|
2017-11-01 00:10:24 +08:00
|
|
|
auto *Def = dyn_cast<Defined>(S);
|
2017-07-28 02:25:59 +08:00
|
|
|
if (Def && Def->isLive() && Def->getChunk())
|
|
|
|
Publics.push_back(createPublic(Def));
|
|
|
|
});
|
2017-07-14 08:14:58 +08:00
|
|
|
|
2017-07-28 02:25:59 +08:00
|
|
|
if (!Publics.empty()) {
|
2019-03-15 02:45:08 +08:00
|
|
|
PublicSymbols = Publics.size();
|
2017-07-28 02:25:59 +08:00
|
|
|
// Sort the public symbols and add them to the stream.
|
2019-02-28 04:53:50 +08:00
|
|
|
parallelSort(Publics, [](const PublicSym32 &L, const PublicSym32 &R) {
|
|
|
|
return L.Name < R.Name;
|
|
|
|
});
|
2017-07-28 02:25:59 +08:00
|
|
|
for (const PublicSym32 &Pub : Publics)
|
2017-08-09 12:23:25 +08:00
|
|
|
GsiBuilder.addPublicSymbol(Pub);
|
2017-07-28 02:25:59 +08:00
|
|
|
}
|
2017-01-12 11:09:25 +08:00
|
|
|
}
|
|
|
|
|
2019-03-15 02:45:08 +08:00
|
|
|
void PDBLinker::printStats() {
|
|
|
|
if (!Config->ShowSummary)
|
|
|
|
return;
|
|
|
|
|
|
|
|
SmallString<256> Buffer;
|
|
|
|
raw_svector_ostream Stream(Buffer);
|
|
|
|
|
|
|
|
Stream << center_justify("Summary", 80) << '\n'
|
|
|
|
<< std::string(80, '-') << '\n';
|
|
|
|
|
|
|
|
auto Print = [&](uint64_t V, StringRef S) {
|
|
|
|
Stream << format_decimal(V, 15) << " " << S << '\n';
|
|
|
|
};
|
|
|
|
|
|
|
|
Print(ObjFile::Instances.size(),
|
|
|
|
"Input OBJ files (expanded from all cmd-line inputs)");
|
|
|
|
Print(TypeServerIndexMappings.size(), "PDB type server dependencies");
|
|
|
|
Print(PrecompTypeIndexMappings.size(), "Precomp OBJ dependencies");
|
2019-04-03 04:43:19 +08:00
|
|
|
Print(TMerger.getTypeTable().size() + TMerger.getIDTable().size(),
|
|
|
|
"Merged TPI records");
|
2019-03-15 02:45:08 +08:00
|
|
|
Print(PDBStrTab.size(), "Output PDB strings");
|
|
|
|
Print(GlobalSymbols, "Global symbol records");
|
|
|
|
Print(ModuleSymbols, "Module symbol records");
|
|
|
|
Print(PublicSymbols, "Public symbol records");
|
|
|
|
|
|
|
|
message(Buffer);
|
|
|
|
}
|
|
|
|
|
2018-03-24 03:57:25 +08:00
|
|
|
void PDBLinker::addNatvisFiles() {
|
|
|
|
for (StringRef File : Config->NatvisFiles) {
|
|
|
|
ErrorOr<std::unique_ptr<MemoryBuffer>> DataOrErr =
|
|
|
|
MemoryBuffer::getFile(File);
|
|
|
|
if (!DataOrErr) {
|
|
|
|
warn("Cannot open input file: " + File);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
Builder.addInjectedSource(File, std::move(*DataOrErr));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-17 02:17:13 +08:00
|
|
|
static codeview::CPUType toCodeViewMachine(COFF::MachineTypes Machine) {
|
|
|
|
switch (Machine) {
|
|
|
|
case COFF::IMAGE_FILE_MACHINE_AMD64:
|
|
|
|
return codeview::CPUType::X64;
|
|
|
|
case COFF::IMAGE_FILE_MACHINE_ARM:
|
|
|
|
return codeview::CPUType::ARM7;
|
|
|
|
case COFF::IMAGE_FILE_MACHINE_ARM64:
|
|
|
|
return codeview::CPUType::ARM64;
|
|
|
|
case COFF::IMAGE_FILE_MACHINE_ARMNT:
|
|
|
|
return codeview::CPUType::ARMNT;
|
|
|
|
case COFF::IMAGE_FILE_MACHINE_I386:
|
|
|
|
return codeview::CPUType::Intel80386;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unsupported CPU Type");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-12-01 00:36:40 +08:00
|
|
|
// Mimic MSVC which surrounds arguments containing whitespace with quotes.
|
|
|
|
// Double double-quotes are handled, so that the resulting string can be
|
|
|
|
// executed again on the cmd-line.
|
|
|
|
static std::string quote(ArrayRef<StringRef> Args) {
|
|
|
|
std::string R;
|
|
|
|
R.reserve(256);
|
|
|
|
for (StringRef A : Args) {
|
|
|
|
if (!R.empty())
|
|
|
|
R.push_back(' ');
|
|
|
|
bool HasWS = A.find(' ') != StringRef::npos;
|
|
|
|
bool HasQ = A.find('"') != StringRef::npos;
|
|
|
|
if (HasWS || HasQ)
|
|
|
|
R.push_back('"');
|
|
|
|
if (HasQ) {
|
|
|
|
SmallVector<StringRef, 4> S;
|
|
|
|
A.split(S, '"');
|
|
|
|
R.append(join(S, "\"\""));
|
|
|
|
} else {
|
|
|
|
R.append(A);
|
|
|
|
}
|
|
|
|
if (HasWS || HasQ)
|
|
|
|
R.push_back('"');
|
|
|
|
}
|
|
|
|
return R;
|
|
|
|
}
|
|
|
|
|
2019-03-30 04:25:34 +08:00
|
|
|
static void fillLinkerVerRecord(Compile3Sym &CS) {
|
2018-04-17 02:17:13 +08:00
|
|
|
CS.Machine = toCodeViewMachine(Config->Machine);
|
2017-08-12 05:14:01 +08:00
|
|
|
// Interestingly, if we set the string to 0.0.0.0, then when trying to view
|
|
|
|
// local variables WinDbg emits an error that private symbols are not present.
|
|
|
|
// By setting this to a valid MSVC linker version string, local variables are
|
|
|
|
// displayed properly. As such, even though it is not representative of
|
2017-08-12 04:46:47 +08:00
|
|
|
// LLVM's version information, we need this for compatibility.
|
2017-07-11 05:01:37 +08:00
|
|
|
CS.Flags = CompileSym3Flags::None;
|
2017-08-12 04:46:47 +08:00
|
|
|
CS.VersionBackendBuild = 25019;
|
|
|
|
CS.VersionBackendMajor = 14;
|
|
|
|
CS.VersionBackendMinor = 10;
|
2017-07-11 05:01:37 +08:00
|
|
|
CS.VersionBackendQFE = 0;
|
2017-08-12 04:46:47 +08:00
|
|
|
|
|
|
|
// MSVC also sets the frontend to 0.0.0.0 since this is specifically for the
|
|
|
|
// linker module (which is by definition a backend), so we don't need to do
|
|
|
|
// anything here. Also, it seems we can use "LLVM Linker" for the linker name
|
|
|
|
// without any problems. Only the backend version has to be hardcoded to a
|
|
|
|
// magic number.
|
2017-07-11 05:01:37 +08:00
|
|
|
CS.VersionFrontendBuild = 0;
|
|
|
|
CS.VersionFrontendMajor = 0;
|
|
|
|
CS.VersionFrontendMinor = 0;
|
|
|
|
CS.VersionFrontendQFE = 0;
|
|
|
|
CS.Version = "LLVM Linker";
|
|
|
|
CS.setLanguage(SourceLanguage::Link);
|
2019-03-30 04:25:34 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void addCommonLinkerModuleSymbols(StringRef Path,
|
|
|
|
pdb::DbiModuleDescriptorBuilder &Mod,
|
|
|
|
BumpPtrAllocator &Allocator) {
|
|
|
|
ObjNameSym ONS(SymbolRecordKind::ObjNameSym);
|
|
|
|
EnvBlockSym EBS(SymbolRecordKind::EnvBlockSym);
|
|
|
|
Compile3Sym CS(SymbolRecordKind::Compile3Sym);
|
|
|
|
fillLinkerVerRecord(CS);
|
|
|
|
|
|
|
|
ONS.Name = "* Linker *";
|
|
|
|
ONS.Signature = 0;
|
2017-07-11 05:01:37 +08:00
|
|
|
|
|
|
|
ArrayRef<StringRef> Args = makeArrayRef(Config->Argv).drop_front();
|
2018-12-01 00:36:40 +08:00
|
|
|
std::string ArgStr = quote(Args);
|
2017-07-11 05:01:37 +08:00
|
|
|
EBS.Fields.push_back("cwd");
|
|
|
|
SmallString<64> cwd;
|
2018-12-07 01:49:15 +08:00
|
|
|
if (Config->PDBSourcePath.empty())
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
sys::fs::current_path(cwd);
|
|
|
|
else
|
|
|
|
cwd = Config->PDBSourcePath;
|
2017-07-11 05:01:37 +08:00
|
|
|
EBS.Fields.push_back(cwd);
|
|
|
|
EBS.Fields.push_back("exe");
|
2017-08-12 04:46:47 +08:00
|
|
|
SmallString<64> exe = Config->Argv[0];
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
pdbMakeAbsolute(exe);
|
2017-08-12 04:46:47 +08:00
|
|
|
EBS.Fields.push_back(exe);
|
2017-07-11 05:01:37 +08:00
|
|
|
EBS.Fields.push_back("pdb");
|
|
|
|
EBS.Fields.push_back(Path);
|
|
|
|
EBS.Fields.push_back("cmd");
|
|
|
|
EBS.Fields.push_back(ArgStr);
|
|
|
|
Mod.addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
ONS, Allocator, CodeViewContainer::Pdb));
|
|
|
|
Mod.addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
CS, Allocator, CodeViewContainer::Pdb));
|
|
|
|
Mod.addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
EBS, Allocator, CodeViewContainer::Pdb));
|
|
|
|
}
|
|
|
|
|
2019-03-30 04:25:34 +08:00
|
|
|
static void addLinkerModuleCoffGroup(PartialSection *Sec,
|
|
|
|
pdb::DbiModuleDescriptorBuilder &Mod,
|
|
|
|
OutputSection &OS,
|
|
|
|
BumpPtrAllocator &Allocator) {
|
|
|
|
// If there's a section, there's at least one chunk
|
|
|
|
assert(!Sec->Chunks.empty());
|
|
|
|
const Chunk *firstChunk = *Sec->Chunks.begin();
|
|
|
|
const Chunk *lastChunk = *Sec->Chunks.rbegin();
|
|
|
|
|
|
|
|
// Emit COFF group
|
|
|
|
CoffGroupSym CGS(SymbolRecordKind::CoffGroupSym);
|
|
|
|
CGS.Name = Sec->Name;
|
|
|
|
CGS.Segment = OS.SectionIndex;
|
|
|
|
CGS.Offset = firstChunk->getRVA() - OS.getRVA();
|
|
|
|
CGS.Size = lastChunk->getRVA() + lastChunk->getSize() - firstChunk->getRVA();
|
|
|
|
CGS.Characteristics = Sec->Characteristics;
|
|
|
|
|
|
|
|
// Somehow .idata sections & sections groups in the debug symbol stream have
|
|
|
|
// the "write" flag set. However the section header for the corresponding
|
|
|
|
// .idata section doesn't have it.
|
|
|
|
if (CGS.Name.startswith(".idata"))
|
|
|
|
CGS.Characteristics |= llvm::COFF::IMAGE_SCN_MEM_WRITE;
|
|
|
|
|
|
|
|
Mod.addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
CGS, Allocator, CodeViewContainer::Pdb));
|
|
|
|
}
|
|
|
|
|
2017-08-12 04:46:28 +08:00
|
|
|
static void addLinkerModuleSectionSymbol(pdb::DbiModuleDescriptorBuilder &Mod,
|
|
|
|
OutputSection &OS,
|
|
|
|
BumpPtrAllocator &Allocator) {
|
|
|
|
SectionSym Sym(SymbolRecordKind::SectionSym);
|
2017-08-12 04:46:47 +08:00
|
|
|
Sym.Alignment = 12; // 2^12 = 4KB
|
2018-04-20 05:48:37 +08:00
|
|
|
Sym.Characteristics = OS.Header.Characteristics;
|
2017-08-12 04:46:28 +08:00
|
|
|
Sym.Length = OS.getVirtualSize();
|
2018-03-16 05:13:46 +08:00
|
|
|
Sym.Name = OS.Name;
|
2017-08-12 04:46:28 +08:00
|
|
|
Sym.Rva = OS.getRVA();
|
|
|
|
Sym.SectionNumber = OS.SectionIndex;
|
|
|
|
Mod.addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
Sym, Allocator, CodeViewContainer::Pdb));
|
2019-03-30 04:25:34 +08:00
|
|
|
|
|
|
|
// Skip COFF groups in MinGW because it adds a significant footprint to the
|
|
|
|
// PDB, due to each function being in its own section
|
|
|
|
if (Config->MinGW)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Output COFF groups for individual chunks of this section.
|
|
|
|
for (PartialSection *Sec : OS.ContribSections) {
|
|
|
|
addLinkerModuleCoffGroup(Sec, Mod, OS, Allocator);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add all import files as modules to the PDB.
|
|
|
|
void PDBLinker::addImportFilesToPDB(ArrayRef<OutputSection *> OutputSections) {
|
|
|
|
if (ImportFile::Instances.empty())
|
|
|
|
return;
|
|
|
|
|
|
|
|
std::map<std::string, llvm::pdb::DbiModuleDescriptorBuilder *> DllToModuleDbi;
|
|
|
|
|
|
|
|
for (ImportFile *File : ImportFile::Instances) {
|
|
|
|
if (!File->Live)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!File->ThunkSym)
|
|
|
|
continue;
|
|
|
|
|
2019-03-30 05:24:19 +08:00
|
|
|
if (!File->ThunkLive)
|
|
|
|
continue;
|
|
|
|
|
2019-03-30 04:25:34 +08:00
|
|
|
std::string DLL = StringRef(File->DLLName).lower();
|
|
|
|
llvm::pdb::DbiModuleDescriptorBuilder *&Mod = DllToModuleDbi[DLL];
|
|
|
|
if (!Mod) {
|
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Builder.getDbiBuilder();
|
|
|
|
SmallString<128> LibPath = File->ParentName;
|
|
|
|
pdbMakeAbsolute(LibPath);
|
|
|
|
sys::path::native(LibPath);
|
|
|
|
|
|
|
|
// Name modules similar to MSVC's link.exe.
|
|
|
|
// The first module is the simple dll filename
|
|
|
|
llvm::pdb::DbiModuleDescriptorBuilder &FirstMod =
|
|
|
|
ExitOnErr(DbiBuilder.addModuleInfo(File->DLLName));
|
|
|
|
FirstMod.setObjFileName(LibPath);
|
|
|
|
pdb::SectionContrib SC =
|
|
|
|
createSectionContrib(nullptr, llvm::pdb::kInvalidStreamIndex);
|
|
|
|
FirstMod.setFirstSectionContrib(SC);
|
|
|
|
|
|
|
|
// The second module is where the import stream goes.
|
|
|
|
Mod = &ExitOnErr(DbiBuilder.addModuleInfo("Import:" + File->DLLName));
|
|
|
|
Mod->setObjFileName(LibPath);
|
|
|
|
}
|
|
|
|
|
|
|
|
DefinedImportThunk *Thunk = cast<DefinedImportThunk>(File->ThunkSym);
|
2019-05-10 05:21:22 +08:00
|
|
|
Chunk *ThunkChunk = Thunk->getChunk();
|
|
|
|
OutputSection *ThunkOS = ThunkChunk->getOutputSection();
|
2019-03-30 04:25:34 +08:00
|
|
|
|
|
|
|
ObjNameSym ONS(SymbolRecordKind::ObjNameSym);
|
|
|
|
Compile3Sym CS(SymbolRecordKind::Compile3Sym);
|
|
|
|
Thunk32Sym TS(SymbolRecordKind::Thunk32Sym);
|
|
|
|
ScopeEndSym ES(SymbolRecordKind::ScopeEndSym);
|
|
|
|
|
|
|
|
ONS.Name = File->DLLName;
|
|
|
|
ONS.Signature = 0;
|
|
|
|
|
|
|
|
fillLinkerVerRecord(CS);
|
|
|
|
|
|
|
|
TS.Name = Thunk->getName();
|
|
|
|
TS.Parent = 0;
|
|
|
|
TS.End = 0;
|
|
|
|
TS.Next = 0;
|
|
|
|
TS.Thunk = ThunkOrdinal::Standard;
|
2019-05-10 05:21:22 +08:00
|
|
|
TS.Length = ThunkChunk->getSize();
|
|
|
|
TS.Segment = ThunkOS->SectionIndex;
|
|
|
|
TS.Offset = ThunkChunk->getRVA() - ThunkOS->getRVA();
|
2019-03-30 04:25:34 +08:00
|
|
|
|
|
|
|
Mod->addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
ONS, Alloc, CodeViewContainer::Pdb));
|
|
|
|
Mod->addSymbol(codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
CS, Alloc, CodeViewContainer::Pdb));
|
|
|
|
|
|
|
|
SmallVector<SymbolScope, 4> Scopes;
|
|
|
|
CVSymbol NewSym = codeview::SymbolSerializer::writeOneSymbol(
|
|
|
|
TS, Alloc, CodeViewContainer::Pdb);
|
|
|
|
scopeStackOpen(Scopes, Mod->getNextSymbolOffset(), NewSym);
|
|
|
|
|
|
|
|
Mod->addSymbol(NewSym);
|
|
|
|
|
|
|
|
NewSym = codeview::SymbolSerializer::writeOneSymbol(ES, Alloc,
|
|
|
|
CodeViewContainer::Pdb);
|
|
|
|
scopeStackClose(Scopes, Mod->getNextSymbolOffset(), File);
|
|
|
|
|
|
|
|
Mod->addSymbol(NewSym);
|
|
|
|
|
|
|
|
pdb::SectionContrib SC =
|
|
|
|
createSectionContrib(Thunk->getChunk(), Mod->getModuleIndex());
|
|
|
|
Mod->setFirstSectionContrib(SC);
|
|
|
|
}
|
2017-08-12 04:46:28 +08:00
|
|
|
}
|
|
|
|
|
2016-11-12 08:00:51 +08:00
|
|
|
// Creates a PDB file.
|
2017-08-04 05:15:09 +08:00
|
|
|
void coff::createPDB(SymbolTable *Symtab,
|
|
|
|
ArrayRef<OutputSection *> OutputSections,
|
|
|
|
ArrayRef<uint8_t> SectionTable,
|
2018-09-16 02:37:22 +08:00
|
|
|
llvm::codeview::DebugInfo *BuildId) {
|
2018-01-18 03:16:26 +08:00
|
|
|
ScopedTimer T1(TotalPdbLinkTimer);
|
2017-07-14 08:14:58 +08:00
|
|
|
PDBLinker PDB(Symtab);
|
2018-03-24 03:57:25 +08:00
|
|
|
|
[LLD COFF/PDB] Incrementally update the build id.
Previously, our algorithm to compute a build id involved hashing the
executable and storing that as the GUID in the CV Debug Record chunk,
and setting the age to 1.
This breaks down in one very obvious case: a user adds some newlines to
a file, rebuilds, but changes nothing else. This causes new line
information and new file checksums to get written to the PDB, meaning
that the debug info is different, but the generated code would be the
same, so we would write the same build over again with an age of 1.
Anyone using a symbol cache would have a problem now, because the
debugger would open the executable, look at the age and guid, find a
matching PDB in the symbol cache and then load it. It would never copy
the new PDB to the symbol cache.
This patch implements the canonical Windows algorithm for updating
a build id, which is to check the existing executable first, and
re-use an existing GUID while bumping the age if it already
exists.
Differential Revision: https://reviews.llvm.org/D36758
llvm-svn: 310961
2017-08-16 05:31:41 +08:00
|
|
|
PDB.initialize(BuildId);
|
2017-07-14 08:14:58 +08:00
|
|
|
PDB.addObjectsToPDB();
|
2019-03-30 04:25:34 +08:00
|
|
|
PDB.addImportFilesToPDB(OutputSections);
|
2017-08-04 05:15:09 +08:00
|
|
|
PDB.addSections(OutputSections, SectionTable);
|
2018-03-24 03:57:25 +08:00
|
|
|
PDB.addNatvisFiles();
|
2018-01-18 03:16:26 +08:00
|
|
|
|
|
|
|
ScopedTimer T2(DiskCommitTimer);
|
2018-09-16 02:37:22 +08:00
|
|
|
codeview::GUID Guid;
|
|
|
|
PDB.commit(&Guid);
|
|
|
|
memcpy(&BuildId->PDB70.Signature, &Guid, 16);
|
2019-03-15 02:45:08 +08:00
|
|
|
|
|
|
|
T2.stop();
|
|
|
|
T1.stop();
|
|
|
|
PDB.printStats();
|
2017-07-14 08:14:58 +08:00
|
|
|
}
|
|
|
|
|
2018-09-16 02:37:22 +08:00
|
|
|
void PDBLinker::initialize(llvm::codeview::DebugInfo *BuildId) {
|
2016-10-01 04:53:45 +08:00
|
|
|
ExitOnErr(Builder.initialize(4096)); // 4096 is blocksize
|
2016-09-16 02:55:18 +08:00
|
|
|
|
2018-09-16 02:37:22 +08:00
|
|
|
BuildId->Signature.CVSignature = OMF::Signature::PDB70;
|
|
|
|
// Signature is set to a hash of the PDB contents when the PDB is done.
|
|
|
|
memset(BuildId->PDB70.Signature, 0, 16);
|
|
|
|
BuildId->PDB70.Age = 1;
|
|
|
|
|
2016-10-06 06:08:58 +08:00
|
|
|
// Create streams in MSF for predefined streams, namely
|
|
|
|
// PDB, TPI, DBI and IPI.
|
|
|
|
for (int I = 0; I < (int)pdb::kSpecialStreamCount; ++I)
|
|
|
|
ExitOnErr(Builder.getMsfBuilder().addStream(0));
|
2016-09-16 02:55:18 +08:00
|
|
|
|
2016-09-17 06:51:17 +08:00
|
|
|
// Add an Info stream.
|
|
|
|
auto &InfoBuilder = Builder.getInfoBuilder();
|
|
|
|
InfoBuilder.setVersion(pdb::PdbRaw_ImplVer::PdbImplVC70);
|
2018-09-16 02:37:22 +08:00
|
|
|
InfoBuilder.setHashPDBContentsToGUID(true);
|
2016-09-16 02:55:18 +08:00
|
|
|
|
2017-07-07 13:04:36 +08:00
|
|
|
// Add an empty DBI stream.
|
2017-06-13 23:49:13 +08:00
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Builder.getDbiBuilder();
|
2018-09-16 02:37:22 +08:00
|
|
|
DbiBuilder.setAge(BuildId->PDB70.Age);
|
Fix some differences between lld and MSVC generated PDBs.
A couple of things were different about our generated PDBs.
1) We were outputting the wrong Version on the PDB Stream.
The version we were setting was newer than what MSVC is setting.
It's not clear what the implications are, but we change LLD
to use PdbImplVC70, as MSVC does.
2) For the optional debug stream indices in the DBI Stream, we
were outputting 0 to mean "the stream is not present". MSVC
outputs uint16_t(-1), which is the "correct" way to specify
that a stream is not present. So we fix that as well.
3) We were setting the PDB Stream signature to 0. This is supposed
to be the result of calling time(nullptr). Although this leads
to non-deterministic builds, a better way to solve that is by
having a command line option explicitly for generating a
reproducible build, and have the default behavior of lld-link
match the default behavior of link.
To test this, I'm making use of the new and improved `pdb diff`
sub command. To make it suitable for writing tests against, I had
to modify the diff subcommand slightly to print less verbose output.
Previously it would always print | <column> | <value1> | <value2> |
which is quite verbose, and the values are fragile. All we really
want to know is "did we produce the same value as link?" So I added
command line options to print a single character representing the
result status (different, identical, equivalent), and another to
hide the value display. Note that just inspecting the diff output
used to write the test, you can see some things that are obviously
wrong. That is just reflective of the fact that this is the state
of affairs today, not that we're asserting that this is "correct".
We can use this as a starting point to discover differences, fix
them, and update the test.
Differential Revision: https://reviews.llvm.org/D35086
llvm-svn: 307422
2017-07-08 02:45:56 +08:00
|
|
|
DbiBuilder.setVersionHeader(pdb::PdbDbiV70);
|
2018-04-17 04:42:06 +08:00
|
|
|
DbiBuilder.setMachineType(Config->Machine);
|
2018-04-17 02:17:13 +08:00
|
|
|
// Technically we are not link.exe 14.11, but there are known cases where
|
|
|
|
// debugging tools on Windows expect Microsoft-specific version numbers or
|
|
|
|
// they fail to work at all. Since we know we produce PDBs that are
|
|
|
|
// compatible with LINK 14.11, we set that version number here.
|
|
|
|
DbiBuilder.setBuildNumber(14, 11);
|
2017-07-14 08:14:58 +08:00
|
|
|
}
|
2016-10-07 06:52:01 +08:00
|
|
|
|
2017-08-04 05:15:09 +08:00
|
|
|
void PDBLinker::addSections(ArrayRef<OutputSection *> OutputSections,
|
|
|
|
ArrayRef<uint8_t> SectionTable) {
|
2017-07-14 08:14:58 +08:00
|
|
|
// It's not entirely clear what this is, but the * Linker * module uses it.
|
2017-08-04 05:15:09 +08:00
|
|
|
pdb::DbiStreamBuilder &DbiBuilder = Builder.getDbiBuilder();
|
2017-07-14 08:14:58 +08:00
|
|
|
NativePath = Config->PDBPath;
|
lld-link: Use /pdbsourcepath: for more places when present.
/pdbsourcepath: was added in https://reviews.llvm.org/D48882 to make it
possible to have relative paths in the debug info that clang-cl writes.
lld-link then makes the paths absolute at link time, which debuggers require.
This way, clang-cl's output is independent of the absolute path of the build
directory, which is useful for cacheability in distcc-like systems.
This patch extends /pdbsourcepath: (if passed) to also be used for:
1. The "cwd" stored in the env block in the pdb is /pdbsourcepath: if present
2. The "exe" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
3. The "pdb" stored in the env block in the pdb is made absolute relative
to /pdbsourcepath: instead of the cwd
4. For making absolute paths to .obj files referenced from the pdb
/pdbsourcepath: is now useful in three scenarios (the first one already working
before this change):
1. When building with full debug info, passing the real build dir to
/pdbsourcepath: allows having clang-cl's output to be independent
of the build directory path. This patch effectively doesn't change
behavior for this use case (assuming the cwd is the build dir).
2. When building without compile-time debug info but linking with /debug,
a fake fixed /pdbsourcepath: can be passed to get symbolized stacks
while making the pdb and exe independent of the current build dir.
For this two work, lld-link needs to be invoked with relative paths for
the lld-link invocation itself (for "exe"), for the pdb output name, the exe
output name (for "pdb"), and the obj input files, and no absolute path
must appear on the link command (for "cmd" in the pdb's env block).
Since no full debug info is present, it doesn't matter that the absolute
path doesn't exist on disk -- we only get symbols in stacks.
3. When building production builds with full debug info that don't have
local changes, and that get source indexed and their pdbs get uploaded
to a symbol server. /pdbsourcepath: again makes the build output independent
of the current directory, and the fixed path passed to /pdbsourcepath: can
be given the source indexing transform so that it gets mapped to a
repository path. This has the same requirements as 2.
This patch also makes it possible to create PDB files containing Windows-style
absolute paths when cross-compiling on a POSIX system.
Differential Revision: https://reviews.llvm.org/D53021
llvm-svn: 344061
2018-10-10 01:52:25 +08:00
|
|
|
pdbMakeAbsolute(NativePath);
|
2017-07-14 08:14:58 +08:00
|
|
|
uint32_t PdbFilePathNI = DbiBuilder.addECName(NativePath);
|
2017-07-07 13:04:36 +08:00
|
|
|
auto &LinkerModule = ExitOnErr(DbiBuilder.addModuleInfo("* Linker *"));
|
|
|
|
LinkerModule.setPdbFilePathNI(PdbFilePathNI);
|
2017-08-12 04:46:28 +08:00
|
|
|
addCommonLinkerModuleSymbols(NativePath, LinkerModule, Alloc);
|
2016-11-16 09:10:46 +08:00
|
|
|
|
2017-08-04 05:15:09 +08:00
|
|
|
// Add section contributions. They must be ordered by ascending RVA.
|
2017-08-12 04:46:28 +08:00
|
|
|
for (OutputSection *OS : OutputSections) {
|
|
|
|
addLinkerModuleSectionSymbol(LinkerModule, *OS, Alloc);
|
2018-09-25 18:59:29 +08:00
|
|
|
for (Chunk *C : OS->Chunks) {
|
2018-04-21 02:00:46 +08:00
|
|
|
pdb::SectionContrib SC =
|
|
|
|
createSectionContrib(C, LinkerModule.getModuleIndex());
|
|
|
|
Builder.getDbiBuilder().addSectionContrib(SC);
|
|
|
|
}
|
2017-08-12 04:46:28 +08:00
|
|
|
}
|
2017-08-04 05:15:09 +08:00
|
|
|
|
2019-03-19 03:13:23 +08:00
|
|
|
// The * Linker * first section contrib is only used along with /INCREMENTAL,
|
|
|
|
// to provide trampolines thunks for incremental function patching. Set this
|
|
|
|
// as "unused" because LLD doesn't support /INCREMENTAL link.
|
|
|
|
pdb::SectionContrib SC =
|
|
|
|
createSectionContrib(nullptr, llvm::pdb::kInvalidStreamIndex);
|
|
|
|
LinkerModule.setFirstSectionContrib(SC);
|
|
|
|
|
2017-08-04 05:15:09 +08:00
|
|
|
// Add Section Map stream.
|
|
|
|
ArrayRef<object::coff_section> Sections = {
|
|
|
|
(const object::coff_section *)SectionTable.data(),
|
|
|
|
SectionTable.size() / sizeof(object::coff_section)};
|
|
|
|
SectionMap = pdb::DbiStreamBuilder::createSectionMap(Sections);
|
|
|
|
DbiBuilder.setSectionMap(SectionMap);
|
|
|
|
|
2016-10-12 03:45:07 +08:00
|
|
|
// Add COFF section header stream.
|
|
|
|
ExitOnErr(
|
|
|
|
DbiBuilder.addDbgStream(pdb::DbgHeaderType::SectionHdr, SectionTable));
|
2017-07-14 08:14:58 +08:00
|
|
|
}
|
2016-10-12 03:45:07 +08:00
|
|
|
|
2018-09-16 02:37:22 +08:00
|
|
|
void PDBLinker::commit(codeview::GUID *Guid) {
|
2016-09-27 07:53:55 +08:00
|
|
|
// Write to a file.
|
2018-09-16 02:37:22 +08:00
|
|
|
ExitOnErr(Builder.commit(Config->PDBPath, Guid));
|
2015-12-05 07:11:05 +08:00
|
|
|
}
|
2018-04-18 07:32:33 +08:00
|
|
|
|
|
|
|
static uint32_t getSecrelReloc() {
|
|
|
|
switch (Config->Machine) {
|
|
|
|
case AMD64:
|
|
|
|
return COFF::IMAGE_REL_AMD64_SECREL;
|
|
|
|
case I386:
|
|
|
|
return COFF::IMAGE_REL_I386_SECREL;
|
|
|
|
case ARMNT:
|
|
|
|
return COFF::IMAGE_REL_ARM_SECREL;
|
|
|
|
case ARM64:
|
|
|
|
return COFF::IMAGE_REL_ARM64_SECREL;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("unknown machine type");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Try to find a line table for the given offset Addr into the given chunk C.
|
|
|
|
// If a line table was found, the line table, the string and checksum tables
|
|
|
|
// that are used to interpret the line table, and the offset of Addr in the line
|
|
|
|
// table are stored in the output arguments. Returns whether a line table was
|
|
|
|
// found.
|
|
|
|
static bool findLineTable(const SectionChunk *C, uint32_t Addr,
|
|
|
|
DebugStringTableSubsectionRef &CVStrTab,
|
|
|
|
DebugChecksumsSubsectionRef &Checksums,
|
|
|
|
DebugLinesSubsectionRef &Lines,
|
|
|
|
uint32_t &OffsetInLinetable) {
|
|
|
|
ExitOnError ExitOnErr;
|
|
|
|
uint32_t SecrelReloc = getSecrelReloc();
|
|
|
|
|
|
|
|
for (SectionChunk *DbgC : C->File->getDebugChunks()) {
|
|
|
|
if (DbgC->getSectionName() != ".debug$S")
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Build a mapping of SECREL relocations in DbgC that refer to C.
|
|
|
|
DenseMap<uint32_t, uint32_t> Secrels;
|
2019-05-04 04:17:14 +08:00
|
|
|
for (const coff_relocation &R : DbgC->getRelocs()) {
|
2018-04-18 07:32:33 +08:00
|
|
|
if (R.Type != SecrelReloc)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (auto *S = dyn_cast_or_null<DefinedRegular>(
|
|
|
|
C->File->getSymbols()[R.SymbolTableIndex]))
|
|
|
|
if (S->getChunk() == C)
|
|
|
|
Secrels[R.VirtualAddress] = S->getValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
ArrayRef<uint8_t> Contents =
|
2019-02-23 09:46:18 +08:00
|
|
|
SectionChunk::consumeDebugMagic(DbgC->getContents(), ".debug$S");
|
2018-04-18 07:32:33 +08:00
|
|
|
DebugSubsectionArray Subsections;
|
|
|
|
BinaryStreamReader Reader(Contents, support::little);
|
|
|
|
ExitOnErr(Reader.readArray(Subsections, Contents.size()));
|
|
|
|
|
|
|
|
for (const DebugSubsectionRecord &SS : Subsections) {
|
|
|
|
switch (SS.kind()) {
|
|
|
|
case DebugSubsectionKind::StringTable: {
|
|
|
|
assert(!CVStrTab.valid() &&
|
|
|
|
"Encountered multiple string table subsections!");
|
|
|
|
ExitOnErr(CVStrTab.initialize(SS.getRecordData()));
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
case DebugSubsectionKind::FileChecksums:
|
|
|
|
assert(!Checksums.valid() &&
|
|
|
|
"Encountered multiple checksum subsections!");
|
|
|
|
ExitOnErr(Checksums.initialize(SS.getRecordData()));
|
|
|
|
break;
|
|
|
|
case DebugSubsectionKind::Lines: {
|
|
|
|
ArrayRef<uint8_t> Bytes;
|
|
|
|
auto Ref = SS.getRecordData();
|
|
|
|
ExitOnErr(Ref.readLongestContiguousChunk(0, Bytes));
|
|
|
|
size_t OffsetInDbgC = Bytes.data() - DbgC->getContents().data();
|
|
|
|
|
|
|
|
// Check whether this line table refers to C.
|
|
|
|
auto I = Secrels.find(OffsetInDbgC);
|
|
|
|
if (I == Secrels.end())
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Check whether this line table covers Addr in C.
|
|
|
|
DebugLinesSubsectionRef LinesTmp;
|
|
|
|
ExitOnErr(LinesTmp.initialize(BinaryStreamReader(Ref)));
|
|
|
|
uint32_t OffsetInC = I->second + LinesTmp.header()->RelocOffset;
|
|
|
|
if (Addr < OffsetInC || Addr >= OffsetInC + LinesTmp.header()->CodeSize)
|
|
|
|
break;
|
|
|
|
|
|
|
|
assert(!Lines.header() &&
|
|
|
|
"Encountered multiple line tables for function!");
|
|
|
|
ExitOnErr(Lines.initialize(BinaryStreamReader(Ref)));
|
|
|
|
OffsetInLinetable = Addr - OffsetInC;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (CVStrTab.valid() && Checksums.valid() && Lines.header())
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Use CodeView line tables to resolve a file and line number for the given
|
|
|
|
// offset into the given chunk and return them, or {"", 0} if a line table was
|
|
|
|
// not found.
|
|
|
|
std::pair<StringRef, uint32_t> coff::getFileLine(const SectionChunk *C,
|
|
|
|
uint32_t Addr) {
|
|
|
|
ExitOnError ExitOnErr;
|
|
|
|
|
|
|
|
DebugStringTableSubsectionRef CVStrTab;
|
|
|
|
DebugChecksumsSubsectionRef Checksums;
|
|
|
|
DebugLinesSubsectionRef Lines;
|
|
|
|
uint32_t OffsetInLinetable;
|
|
|
|
|
|
|
|
if (!findLineTable(C, Addr, CVStrTab, Checksums, Lines, OffsetInLinetable))
|
|
|
|
return {"", 0};
|
|
|
|
|
2019-01-05 05:49:22 +08:00
|
|
|
Optional<uint32_t> NameIndex;
|
|
|
|
Optional<uint32_t> LineNumber;
|
2018-04-18 07:32:33 +08:00
|
|
|
for (LineColumnEntry &Entry : Lines) {
|
|
|
|
for (const LineNumberEntry &LN : Entry.LineNumbers) {
|
2019-01-05 05:49:22 +08:00
|
|
|
LineInfo LI(LN.Flags);
|
2018-04-18 07:32:33 +08:00
|
|
|
if (LN.Offset > OffsetInLinetable) {
|
2019-01-05 05:49:22 +08:00
|
|
|
if (!NameIndex) {
|
|
|
|
NameIndex = Entry.NameIndex;
|
|
|
|
LineNumber = LI.getStartLine();
|
|
|
|
}
|
2018-04-18 07:32:33 +08:00
|
|
|
StringRef Filename =
|
2019-01-05 05:49:22 +08:00
|
|
|
ExitOnErr(getFileName(CVStrTab, Checksums, *NameIndex));
|
|
|
|
return {Filename, *LineNumber};
|
2018-04-18 07:32:33 +08:00
|
|
|
}
|
|
|
|
NameIndex = Entry.NameIndex;
|
|
|
|
LineNumber = LI.getStartLine();
|
|
|
|
}
|
|
|
|
}
|
2019-01-05 05:49:22 +08:00
|
|
|
if (!NameIndex)
|
|
|
|
return {"", 0};
|
|
|
|
StringRef Filename = ExitOnErr(getFileName(CVStrTab, Checksums, *NameIndex));
|
|
|
|
return {Filename, *LineNumber};
|
2018-04-18 07:32:33 +08:00
|
|
|
}
|