2aa020f49b
In a PR last month I changed the ObjectFile CreateInstance etc methods to accept an optional DataExtractorSP instead of a DataBufferSP, and retain the extractor in a shared pointer internally in all of the ObjectFile subclasses. This is laying the groundwork for using a VirtualDataExtractor for some Mach-O binaries on macOS, where the segments of the binary are out-of-order in actual memory, and we add a lookup table to make it appear that the TEXT segment is at offset 0 in the Extractor, etc. Working on the actual implementation, I realized we were still using DataBufferSP's in ModuleSpec and Module, as well as in ObjectFile::GetModuleSpecifications. I originally was making a much larger NFC change where I had all ObjectFile subclasses operating on DataExtractors throughout their implementation, as well as in the DWARF parser. It was a very large patchset. Many subclasses start with their DataExtractor, then create smaller DataExtractors for parts of the binary image - the string table, the symbol table, etc., for processing. After consideration and discussion with Jonas, we agreed that a segment/section of a binary will never require a lookup table to access the bytes within it, so I changed VirtualDataExtractor::GetSubsetExtractorSP to (1) require that the Subset be contained within a single lookup table entry, and (2) return a simple DataExtractor bounded on that byte range. By doing this, I was able to remove all of my very-invasive changes to the ObjectFile subclass internals; it's only when they are operating on the entire binary image that care is needed. One pattern that subclasses like ObjectFileBreakpad use is to take an ArrayRef of the DataBuffer for a binary, then create a StringRef of that, then look for strings in it. With a VirtualDataExtractor and out-of-order binary segments, with gaps between them, this allows us to search the entire buffer looking for a string, and segfault when it gets to an unmapped region of the buffer. I added a VirtualDataExtractor::GetSubsetExtractorSP(0) which gets the largest contiguous memory region starting at offset 0 for this use case, and I added a comment about what was being done there because I know it is not obvious, and people not working on macOS wouldn't be familiar with the requirement. (when we have a ModuleSpec with a DataExtractor, any of the ObjectFile subclasses get a shot at Creating, so they all have to be able to iterate on these) rdar://148939795
71 lines
2.6 KiB
C++
71 lines
2.6 KiB
C++
//===-- ObjectContainerBigArchive.cpp -------------------------------------===//
|
|
//
|
|
// 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
|
|
//
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "ObjectContainerBigArchive.h"
|
|
#include "lldb/Core/Module.h"
|
|
#include "lldb/Core/ModuleSpec.h"
|
|
#include "lldb/Core/PluginManager.h"
|
|
#include "lldb/Utility/ArchSpec.h"
|
|
|
|
using namespace lldb;
|
|
using namespace lldb_private;
|
|
|
|
LLDB_PLUGIN_DEFINE(ObjectContainerBigArchive)
|
|
|
|
ObjectContainerBigArchive::Archive::Archive(const lldb_private::ArchSpec &arch,
|
|
const llvm::sys::TimePoint<> &time,
|
|
lldb::offset_t file_offset,
|
|
lldb::DataExtractorSP extractor_sp)
|
|
: m_arch(arch), m_modification_time(time), m_file_offset(file_offset),
|
|
m_objects(), m_extractor_sp(extractor_sp) {}
|
|
|
|
ObjectContainerBigArchive::Archive::~Archive() = default;
|
|
|
|
void ObjectContainerBigArchive::Initialize() {
|
|
PluginManager::RegisterPlugin(GetPluginNameStatic(),
|
|
GetPluginDescriptionStatic(), CreateInstance,
|
|
GetModuleSpecifications);
|
|
}
|
|
|
|
void ObjectContainerBigArchive::Terminate() {
|
|
PluginManager::UnregisterPlugin(CreateInstance);
|
|
}
|
|
|
|
ObjectContainer *ObjectContainerBigArchive::CreateInstance(
|
|
const lldb::ModuleSP &module_sp, DataBufferSP &data_sp,
|
|
lldb::offset_t data_offset, const FileSpec *file,
|
|
lldb::offset_t file_offset, lldb::offset_t length) {
|
|
return nullptr;
|
|
}
|
|
|
|
size_t ObjectContainerBigArchive::GetModuleSpecifications(
|
|
const lldb_private::FileSpec &file, lldb::DataExtractorSP &extractor_sp,
|
|
lldb::offset_t data_offset, lldb::offset_t file_offset,
|
|
lldb::offset_t file_size, lldb_private::ModuleSpecList &specs) {
|
|
return 0;
|
|
}
|
|
|
|
ObjectContainerBigArchive::ObjectContainerBigArchive(
|
|
const lldb::ModuleSP &module_sp, DataBufferSP &data_sp,
|
|
lldb::offset_t data_offset, const lldb_private::FileSpec *file,
|
|
lldb::offset_t file_offset, lldb::offset_t size)
|
|
: ObjectContainer(module_sp, file, file_offset, size, data_sp, data_offset),
|
|
m_archive_sp() {}
|
|
|
|
void ObjectContainerBigArchive::SetArchive(Archive::shared_ptr &archive_sp) {
|
|
m_archive_sp = archive_sp;
|
|
}
|
|
|
|
ObjectContainerBigArchive::~ObjectContainerBigArchive() = default;
|
|
|
|
bool ObjectContainerBigArchive::ParseHeader() { return false; }
|
|
|
|
ObjectFileSP ObjectContainerBigArchive::GetObjectFile(const FileSpec *file) {
|
|
return ObjectFileSP();
|
|
}
|