2015-01-06 05:29:28 +08:00
|
|
|
//===-- BinaryHolder.cpp --------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This program is a utility that aims to be a dropin replacement for
|
|
|
|
// Darwin's dsymutil.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "BinaryHolder.h"
|
2015-07-24 14:41:04 +08:00
|
|
|
#include "llvm/Object/MachO.h"
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
#include "llvm/Support/WithColor.h"
|
2015-01-06 05:29:28 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
namespace dsymutil {
|
|
|
|
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
static std::pair<StringRef, StringRef>
|
|
|
|
getArchiveAndObjectName(StringRef Filename) {
|
|
|
|
StringRef Archive = Filename.substr(0, Filename.find('('));
|
|
|
|
StringRef Object = Filename.substr(Archive.size() + 1).drop_back();
|
|
|
|
return {Archive, Object};
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool isArchive(StringRef Filename) { return Filename.endswith(")"); }
|
|
|
|
|
2015-07-24 14:41:11 +08:00
|
|
|
static std::vector<MemoryBufferRef>
|
|
|
|
getMachOFatMemoryBuffers(StringRef Filename, MemoryBuffer &Mem,
|
|
|
|
object::MachOUniversalBinary &Fat) {
|
|
|
|
std::vector<MemoryBufferRef> Buffers;
|
|
|
|
StringRef FatData = Fat.getData();
|
|
|
|
for (auto It = Fat.begin_objects(), End = Fat.end_objects(); It != End;
|
|
|
|
++It) {
|
|
|
|
StringRef ObjData = FatData.substr(It->getOffset(), It->getSize());
|
|
|
|
Buffers.emplace_back(ObjData, Filename);
|
|
|
|
}
|
|
|
|
return Buffers;
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:51:52 +08:00
|
|
|
Error BinaryHolder::ArchiveEntry::load(StringRef Filename,
|
|
|
|
TimestampTy Timestamp, bool Verbose) {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
StringRef ArchiveFilename = getArchiveAndObjectName(Filename).first;
|
|
|
|
|
|
|
|
// Try to load archive and force it to be memory mapped.
|
|
|
|
auto ErrOrBuff = MemoryBuffer::getFileOrSTDIN(ArchiveFilename, -1, false);
|
|
|
|
if (auto Err = ErrOrBuff.getError())
|
|
|
|
return errorCodeToError(Err);
|
|
|
|
|
2018-06-30 01:11:34 +08:00
|
|
|
MemBuffer = std::move(*ErrOrBuff);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
|
|
|
|
if (Verbose)
|
2018-06-30 00:51:52 +08:00
|
|
|
WithColor::note() << "loaded archive '" << ArchiveFilename << "'\n";
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
|
|
|
|
// Load one or more archive buffers, depending on whether we're dealing with
|
|
|
|
// a fat binary.
|
|
|
|
std::vector<MemoryBufferRef> ArchiveBuffers;
|
|
|
|
|
|
|
|
auto ErrOrFat =
|
2018-06-30 01:11:34 +08:00
|
|
|
object::MachOUniversalBinary::create(MemBuffer->getMemBufferRef());
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
if (!ErrOrFat) {
|
|
|
|
consumeError(ErrOrFat.takeError());
|
2018-06-30 01:11:34 +08:00
|
|
|
ArchiveBuffers.push_back(MemBuffer->getMemBufferRef());
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
} else {
|
|
|
|
FatBinary = std::move(*ErrOrFat);
|
|
|
|
FatBinaryName = ArchiveFilename;
|
|
|
|
ArchiveBuffers =
|
2018-06-30 01:11:34 +08:00
|
|
|
getMachOFatMemoryBuffers(FatBinaryName, *MemBuffer, *FatBinary);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, try to load the archives.
|
|
|
|
Archives.reserve(ArchiveBuffers.size());
|
|
|
|
for (auto MemRef : ArchiveBuffers) {
|
|
|
|
auto ErrOrArchive = object::Archive::create(MemRef);
|
|
|
|
if (!ErrOrArchive)
|
|
|
|
return ErrOrArchive.takeError();
|
|
|
|
Archives.push_back(std::move(*ErrOrArchive));
|
|
|
|
}
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:51:52 +08:00
|
|
|
Error BinaryHolder::ObjectEntry::load(StringRef Filename, bool Verbose) {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
// Try to load regular binary and force it to be memory mapped.
|
|
|
|
auto ErrOrBuff = MemoryBuffer::getFileOrSTDIN(Filename, -1, false);
|
|
|
|
if (auto Err = ErrOrBuff.getError())
|
|
|
|
return errorCodeToError(Err);
|
|
|
|
|
2018-06-30 01:11:34 +08:00
|
|
|
MemBuffer = std::move(*ErrOrBuff);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
|
|
|
|
if (Verbose)
|
2018-06-30 00:51:52 +08:00
|
|
|
WithColor::note() << "loaded object.\n";
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
|
|
|
|
// Load one or more object buffers, depending on whether we're dealing with a
|
|
|
|
// fat binary.
|
|
|
|
std::vector<MemoryBufferRef> ObjectBuffers;
|
|
|
|
|
|
|
|
auto ErrOrFat =
|
2018-06-30 01:11:34 +08:00
|
|
|
object::MachOUniversalBinary::create(MemBuffer->getMemBufferRef());
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
if (!ErrOrFat) {
|
|
|
|
consumeError(ErrOrFat.takeError());
|
2018-06-30 01:11:34 +08:00
|
|
|
ObjectBuffers.push_back(MemBuffer->getMemBufferRef());
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
} else {
|
|
|
|
FatBinary = std::move(*ErrOrFat);
|
|
|
|
FatBinaryName = Filename;
|
|
|
|
ObjectBuffers =
|
2018-06-30 01:11:34 +08:00
|
|
|
getMachOFatMemoryBuffers(FatBinaryName, *MemBuffer, *FatBinary);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
Objects.reserve(ObjectBuffers.size());
|
|
|
|
for (auto MemRef : ObjectBuffers) {
|
|
|
|
auto ErrOrObjectFile = object::ObjectFile::createObjectFile(MemRef);
|
|
|
|
if (!ErrOrObjectFile)
|
|
|
|
return ErrOrObjectFile.takeError();
|
|
|
|
Objects.push_back(std::move(*ErrOrObjectFile));
|
|
|
|
}
|
|
|
|
|
|
|
|
return Error::success();
|
|
|
|
}
|
|
|
|
|
|
|
|
std::vector<const object::ObjectFile *>
|
2018-06-30 00:51:52 +08:00
|
|
|
BinaryHolder::ObjectEntry::getObjects() const {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
std::vector<const object::ObjectFile *> Result;
|
|
|
|
Result.reserve(Objects.size());
|
|
|
|
for (auto &Object : Objects) {
|
|
|
|
Result.push_back(Object.get());
|
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
Expected<const object::ObjectFile &>
|
2018-06-30 00:51:52 +08:00
|
|
|
BinaryHolder::ObjectEntry::getObject(const Triple &T) const {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
for (const auto &Obj : Objects) {
|
|
|
|
if (const auto *MachO = dyn_cast<object::MachOObjectFile>(Obj.get())) {
|
|
|
|
if (MachO->getArchTriple().str() == T.str())
|
|
|
|
return *MachO;
|
|
|
|
} else if (Obj->getArch() == T.getArch())
|
|
|
|
return *Obj;
|
|
|
|
}
|
|
|
|
return errorCodeToError(object::object_error::arch_not_found);
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:51:52 +08:00
|
|
|
Expected<const BinaryHolder::ObjectEntry &>
|
|
|
|
BinaryHolder::ArchiveEntry::getObjectEntry(StringRef Filename,
|
|
|
|
TimestampTy Timestamp,
|
|
|
|
bool Verbose) {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
StringRef ArchiveFilename;
|
|
|
|
StringRef ObjectFilename;
|
|
|
|
std::tie(ArchiveFilename, ObjectFilename) = getArchiveAndObjectName(Filename);
|
|
|
|
|
|
|
|
// Try the cache first.
|
|
|
|
KeyTy Key = {ObjectFilename, Timestamp};
|
|
|
|
|
|
|
|
{
|
|
|
|
std::lock_guard<std::mutex> Lock(MemberCacheMutex);
|
|
|
|
if (MemberCache.count(Key))
|
|
|
|
return MemberCache[Key];
|
|
|
|
}
|
|
|
|
|
|
|
|
// Create a new ObjectEntry, but don't add it to the cache yet. Loading of
|
|
|
|
// the archive members might fail and we don't want to lock the whole archive
|
|
|
|
// during this operation.
|
|
|
|
ObjectEntry OE;
|
|
|
|
|
|
|
|
for (const auto &Archive : Archives) {
|
|
|
|
Error Err = Error::success();
|
|
|
|
for (auto Child : Archive->children(Err)) {
|
|
|
|
if (auto NameOrErr = Child.getName()) {
|
|
|
|
if (*NameOrErr == ObjectFilename) {
|
|
|
|
auto ModTimeOrErr = Child.getLastModified();
|
|
|
|
if (!ModTimeOrErr)
|
|
|
|
return ModTimeOrErr.takeError();
|
|
|
|
|
|
|
|
if (Timestamp != sys::TimePoint<>() &&
|
|
|
|
Timestamp != ModTimeOrErr.get()) {
|
|
|
|
if (Verbose)
|
|
|
|
WithColor::warning() << "member has timestamp mismatch.\n";
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Verbose)
|
2018-06-30 00:51:52 +08:00
|
|
|
WithColor::note() << "found member in archive.\n";
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
|
|
|
|
auto ErrOrMem = Child.getMemoryBufferRef();
|
|
|
|
if (!ErrOrMem)
|
|
|
|
return ErrOrMem.takeError();
|
|
|
|
|
|
|
|
auto ErrOrObjectFile =
|
|
|
|
object::ObjectFile::createObjectFile(*ErrOrMem);
|
|
|
|
if (!ErrOrObjectFile)
|
|
|
|
return ErrOrObjectFile.takeError();
|
|
|
|
|
|
|
|
OE.Objects.push_back(std::move(*ErrOrObjectFile));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (Err)
|
|
|
|
return std::move(Err);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OE.Objects.empty())
|
|
|
|
return errorCodeToError(errc::no_such_file_or_directory);
|
|
|
|
|
|
|
|
std::lock_guard<std::mutex> Lock(MemberCacheMutex);
|
|
|
|
MemberCache.try_emplace(Key, std::move(OE));
|
|
|
|
return MemberCache[Key];
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:51:52 +08:00
|
|
|
Expected<const BinaryHolder::ObjectEntry &>
|
|
|
|
BinaryHolder::getObjectEntry(StringRef Filename, TimestampTy Timestamp) {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
if (Verbose)
|
|
|
|
WithColor::note() << "trying to open '" << Filename << "'\n";
|
|
|
|
|
|
|
|
// If this is an archive, we might have either the object or the archive
|
|
|
|
// cached. In this case we can load it without accessing the file system.
|
|
|
|
if (isArchive(Filename)) {
|
|
|
|
StringRef ArchiveFilename = getArchiveAndObjectName(Filename).first;
|
|
|
|
std::lock_guard<std::mutex> Lock(ArchiveCacheMutex);
|
|
|
|
if (ArchiveCache.count(ArchiveFilename)) {
|
2018-06-30 00:51:52 +08:00
|
|
|
return ArchiveCache[ArchiveFilename].getObjectEntry(Filename, Timestamp,
|
|
|
|
Verbose);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
} else {
|
|
|
|
ArchiveEntry &AE = ArchiveCache[ArchiveFilename];
|
|
|
|
auto Err = AE.load(Filename, Timestamp, Verbose);
|
|
|
|
if (Err) {
|
|
|
|
ArchiveCache.erase(ArchiveFilename);
|
|
|
|
// Don't return the error here: maybe the file wasn't an archive.
|
|
|
|
llvm::consumeError(std::move(Err));
|
|
|
|
} else {
|
2018-06-30 00:51:52 +08:00
|
|
|
return ArchiveCache[ArchiveFilename].getObjectEntry(Filename, Timestamp,
|
|
|
|
Verbose);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If this is an object, we might have it cached. If not we'll have to load
|
|
|
|
// it from the file system and cache it now.
|
|
|
|
std::lock_guard<std::mutex> Lock(ObjectCacheMutex);
|
|
|
|
if (!ObjectCache.count(Filename)) {
|
|
|
|
ObjectEntry &OE = ObjectCache[Filename];
|
2018-06-30 00:51:52 +08:00
|
|
|
auto Err = OE.load(Filename, Verbose);
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
if (Err) {
|
|
|
|
ObjectCache.erase(Filename);
|
|
|
|
return std::move(Err);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return ObjectCache[Filename];
|
|
|
|
}
|
|
|
|
|
2018-06-30 00:51:52 +08:00
|
|
|
void BinaryHolder::clear() {
|
[dsymutil] Introduce a new CachedBinaryHolder
The original binary holder has an optimization where it caches a static
library (archive) between consecutive calls to GetObjects. However, the
actual memory buffer wasn't cached between calls.
This made sense when dsymutil was processing objects one after each
other, but when processing them in parallel, several binaries have to be
in memory at the same time. For this reason, every link context
contained a binary holder.
Having one binary holder per context is problematic, because the same
static archive was cached for every object file. Luckily, when the file
is mmap'ed, this was only costing us virtual memory.
This patch introduces a new BinaryHolder variant that is fully cached,
for all the object files it load, as well as the static archives. This
way, we don't have to give up on this optimization of bypassing the
file system.
Differential revision: https://reviews.llvm.org/D48501
llvm-svn: 335990
2018-06-30 00:50:41 +08:00
|
|
|
std::lock_guard<std::mutex> ArchiveLock(ArchiveCacheMutex);
|
|
|
|
std::lock_guard<std::mutex> ObjectLock(ObjectCacheMutex);
|
|
|
|
ArchiveCache.clear();
|
|
|
|
ObjectCache.clear();
|
|
|
|
}
|
|
|
|
|
2018-02-22 19:32:51 +08:00
|
|
|
} // namespace dsymutil
|
|
|
|
} // namespace llvm
|