intel/llvm
1
0
Fork 0
mirror of https://github.com/intel/llvm.git synced 2026-01-16 21:55:39 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
c6c7bfc4d2bc37f55f57504c19d47deb7645dd76
llvm/lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.h

222 lines
8.6 KiB
C
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
//===-- ObjectFileMachO.h ---------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#ifndef liblldb_ObjectFileMachO_h_
#define liblldb_ObjectFileMachO_h_
Fix Clang-tidy modernize-use-override warnings in source/Plugins/ObjectContainer and ObjectFile; other minor fixes. llvm-svn: 251119
2015-10-23 16:56:07 +00:00
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
Add a method "GetEntryPoint" to the ObjectFile class, and implement it on MachO & ELF - though the ELF implementation is probably a little weak. Then use this method in place of directly looking for "start" in the ThreadPlanCallFunction constructor to find the stopping point for our function evaluation. llvm-svn: 127194
2011-03-07 23:44:08 +00:00
#include "lldb/Core/Address.h"
ReExported symbols can point to a library that doesn't actually contain the symbol, but just reexports wholesale from another library. Handle this case. <rdar://problem/16977589> llvm-svn: 209270
2014-05-21 03:58:03 +00:00
#include "lldb/Core/FileSpecList.h"
First pass at mach-o core file support is in. It currently works for x86_64 user space programs. The core file support is implemented by making a process plug-in that will dress up the threads and stack frames by using the core file memory. Added many default implementations for the lldb_private::Process functions so that plug-ins like the ProcessMachCore don't need to override many many functions only to have to return an error. Added new virtual functions to the ObjectFile class for extracting the frozen thread states that might be stored in object files. The default implementations return no thread information, but any platforms that support core files that contain frozen thread states (like mach-o) can make a module using the core file and then extract the information. The object files can enumerate the threads and also provide the register state for each thread. Since each object file knows how the thread registers are stored, they are responsible for creating a suitable register context that can be used by the core file threads. Changed the process CreateInstace callbacks to return a shared pointer and to also take an "const FileSpec *core_file" parameter to allow for core file support. This will also allow for lldb_private::Process subclasses to be made that could load crash logs. This should be possible on darwin where the crash logs contain all of the stack frames for all of the threads, yet the crash logs only contain the registers for the crashed thrad. It should also allow some variables to be viewed for the thread that crashed. llvm-svn: 150154
2012-02-09 06:16:32 +00:00
#include "lldb/Core/RangeMap.h"
Move SafeMachO from Utility to Host Summary: One of the conclusions of the discussion on D49740 was that SafeMachO is better off in the Host module (as that's the only place which should include mach/machine.h, which is what this header is working around). Also, Utility, which is the only module which cannot include Host, should not be doing anything with object file formats. This patch implements that move, and also removes any unneded includes of that file. I've verified that MacOS still compiles after this. Reviewers: jingham, zturner, teemperor Subscribers: fedor.sergeev, lldb-commits Differential Revision: https://reviews.llvm.org/D50383 llvm-svn: 342050
2018-09-12 12:26:05 +00:00
#include "lldb/Host/SafeMachO.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
#include "lldb/Symbol/ObjectFile.h"
Move FileSpec from Host -> Utility. llvm-svn: 298536
2017-03-22 18:40:07 +00:00
#include "lldb/Utility/FileSpec.h"
Use two LC_NOTE load commands for identifying the main binary that lldb should use when given a corefile. This uses an LC_NOTE "main bin spec" or an LC_NOTE "kern ver str" if they are present in a Mach-O core file. Core files may have multiple different binaries -- different kernels, or a mix of user process and kernel binaries -- and it can be difficult for lldb to detect the correct one to use simply by looking at the pages of memory. These two new LC_NOTE load commands allow for the correct binary to be recorded unambiguously. <rdar://problem/20878266> llvm-svn: 300138
2017-04-12 23:33:30 +00:00
#include "lldb/Utility/UUID.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
//----------------------------------------------------------------------
// This class needs to be hidden as eventually belongs in a plugin that
// will export the ObjectFile protocol
//----------------------------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
class ObjectFileMachO : public lldb_private::ObjectFile {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
public:
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
ObjectFileMachO(const lldb::ModuleSP &module_sp, lldb::DataBufferSP &data_sp,
lldb::offset_t data_offset,
const lldb_private::FileSpec *file, lldb::offset_t offset,
lldb::offset_t length);
ObjectFileMachO(const lldb::ModuleSP &module_sp, lldb::DataBufferSP &data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
~ObjectFileMachO() override = default;
//------------------------------------------------------------------
// Static Functions
//------------------------------------------------------------------
static void Initialize();
static void Terminate();
static lldb_private::ConstString GetPluginNameStatic();
static const char *GetPluginDescriptionStatic();
static lldb_private::ObjectFile *
CreateInstance(const lldb::ModuleSP &module_sp, lldb::DataBufferSP &data_sp,
lldb::offset_t data_offset, const lldb_private::FileSpec *file,
lldb::offset_t file_offset, lldb::offset_t length);
static lldb_private::ObjectFile *CreateMemoryInstance(
const lldb::ModuleSP &module_sp, lldb::DataBufferSP &data_sp,
const lldb::ProcessSP &process_sp, lldb::addr_t header_addr);
static size_t GetModuleSpecifications(const lldb_private::FileSpec &file,
lldb::DataBufferSP &data_sp,
lldb::offset_t data_offset,
lldb::offset_t file_offset,
lldb::offset_t length,
lldb_private::ModuleSpecList &specs);
static bool SaveCore(const lldb::ProcessSP &process_sp,
const lldb_private::FileSpec &outfile,
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 04:51:55 +00:00
lldb_private::Status &error);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
static bool MagicBytesMatch(lldb::DataBufferSP &data_sp, lldb::addr_t offset,
lldb::addr_t length);
//------------------------------------------------------------------
// Member Functions
//------------------------------------------------------------------
bool ParseHeader() override;
bool SetLoadAddress(lldb_private::Target &target, lldb::addr_t value,
bool value_is_offset) override;
lldb::ByteOrder GetByteOrder() const override;
bool IsExecutable() const override;
uint32_t GetAddressByteSize() const override;
Move AddressClass to private enums since API doesn't provide any functions to manage it. This change allows to make AddressClass strongly typed enum and not to have issues with old versions of SWIG that don't support enum classes. llvm-svn: 335710
2018-06-27 06:50:10 +00:00
lldb_private::AddressClass GetAddressClass(lldb::addr_t file_addr) override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
lldb_private::Symtab *GetSymtab() override;
bool IsStripped() override;
void CreateSections(lldb_private::SectionList &unified_section_list) override;
void Dump(lldb_private::Stream *s) override;
bool GetArchitecture(lldb_private::ArchSpec &arch) override;
bool GetUUID(lldb_private::UUID *uuid) override;
uint32_t GetDependentModules(lldb_private::FileSpecList &files) override;
lldb_private::FileSpecList GetReExportedLibraries() override {
return m_reexported_dylibs;
}
lldb_private::Address GetEntryPointAddress() override;
lldb_private::Address GetHeaderAddress() override;
uint32_t GetNumThreadContexts() override;
Some old mach-o core files have an LC_IDENT load command and there's a string in there that can be helpful in locating the kernel binary. Use it. <rdar://problem/31444711> llvm-svn: 299612
2017-04-06 01:50:11 +00:00
std::string GetIdentifierString() override;
Use two LC_NOTE load commands for identifying the main binary that lldb should use when given a corefile. This uses an LC_NOTE "main bin spec" or an LC_NOTE "kern ver str" if they are present in a Mach-O core file. Core files may have multiple different binaries -- different kernels, or a mix of user process and kernel binaries -- and it can be difficult for lldb to detect the correct one to use simply by looking at the pages of memory. These two new LC_NOTE load commands allow for the correct binary to be recorded unambiguously. <rdar://problem/20878266> llvm-svn: 300138
2017-04-12 23:33:30 +00:00
bool GetCorefileMainBinaryInfo (lldb::addr_t &address, lldb_private::UUID &uuid) override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
lldb::RegisterContextSP
GetThreadContextAtIndex(uint32_t idx, lldb_private::Thread &thread) override;
ObjectFile::Type CalculateType() override;
ObjectFile::Strata CalculateStrata() override;
Use llvm::VersionTuple instead of manual version marshalling Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
2018-06-18 15:02:23 +00:00
llvm::VersionTuple GetVersion() override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
Use llvm::VersionTuple instead of manual version marshalling Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
2018-06-18 15:02:23 +00:00
llvm::VersionTuple GetMinimumOSVersion() override;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
uint32_t GetSDKVersion(uint32_t *versions, uint32_t num_versions) override;
bool GetIsDynamicLinkEditor() override;
static bool ParseHeader(lldb_private::DataExtractor &data,
lldb::offset_t *data_offset_ptr,
llvm::MachO::mach_header &header);
bool AllowAssemblyEmulationUnwindPlans() override;
//------------------------------------------------------------------
// PluginInterface protocol
//------------------------------------------------------------------
lldb_private::ConstString GetPluginName() override;
uint32_t GetPluginVersion() override;
Fix Clang-tidy modernize-use-override warnings in source/Plugins/ObjectContainer and ObjectFile; other minor fixes. llvm-svn: 251119
2015-10-23 16:56:07 +00:00
Verify we have a correct ELF or Mach core file before we return a valid instace of ProcessElfCore or ProcessMachCore respectively. llvm-svn: 203274
2014-03-07 19:24:39 +00:00
protected:
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
static bool
GetUUID(const llvm::MachO::mach_header &header,
const lldb_private::DataExtractor &data,
lldb::offset_t lc_offset, // Offset to the first load command
lldb_private::UUID &uuid);
static bool GetArchitecture(const llvm::MachO::mach_header &header,
const lldb_private::DataExtractor &data,
lldb::offset_t lc_offset,
lldb_private::ArchSpec &arch);
// Intended for same-host arm device debugging where lldb needs to
// detect libraries in the shared cache and augment the nlist entries
// with an on-disk dyld_shared_cache file. The process will record
// the shared cache UUID so the on-disk cache can be matched or rejected
// correctly.
The on-ios-device command line lldb has an optimization where when it and the inferior process both have the same shared cache (a conglomeration of all libraries at the same fixed address for all processes), lldb will read data out of its own memory to speed things up. The shared cache has a UUID, so lldb currently checks that the UUID of its own shared cache matches that of the inferior. This change adds one refinement to that -- it checks that the UUID is the same and that the base address of the shared cache is the same. And only uses its local shared cache if they are both identical. This involved using a different style of SPI with dyld to get lldb's shared cache load address, but it's not especially difficult. One unattractive part of the change is that I'm using the real underlying types of task_t and kern_return_t instead of picking them up from mach/mach.h. The defines that get picked up there (a lot from machine.h but others too) conflict with llvm/Support/MachO.h even when I have mach.h included before our SafeMachO.h which undefines most of the defines before including llvm/Support/MachO.h. I'll need to augment the #undefs in SafeMachO.h to get this to compile cleanly, but that'll be another day. <rdar://problem/39868238> llvm-svn: 331497
2018-05-04 00:59:37 +00:00
void GetProcessSharedCacheUUID(lldb_private::Process *, lldb::addr_t &base_addr, lldb_private::UUID &uuid);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
// Intended for same-host arm device debugging where lldb will read
// shared cache libraries out of its own memory instead of the remote
// process' memory as an optimization. If lldb's shared cache UUID
// does not match the process' shared cache UUID, this optimization
// should not be used.
The on-ios-device command line lldb has an optimization where when it and the inferior process both have the same shared cache (a conglomeration of all libraries at the same fixed address for all processes), lldb will read data out of its own memory to speed things up. The shared cache has a UUID, so lldb currently checks that the UUID of its own shared cache matches that of the inferior. This change adds one refinement to that -- it checks that the UUID is the same and that the base address of the shared cache is the same. And only uses its local shared cache if they are both identical. This involved using a different style of SPI with dyld to get lldb's shared cache load address, but it's not especially difficult. One unattractive part of the change is that I'm using the real underlying types of task_t and kern_return_t instead of picking them up from mach/mach.h. The defines that get picked up there (a lot from machine.h but others too) conflict with llvm/Support/MachO.h even when I have mach.h included before our SafeMachO.h which undefines most of the defines before including llvm/Support/MachO.h. I'll need to augment the #undefs in SafeMachO.h to get this to compile cleanly, but that'll be another day. <rdar://problem/39868238> llvm-svn: 331497
2018-05-04 00:59:37 +00:00
void GetLLDBSharedCacheUUID(lldb::addr_t &base_addir, lldb_private::UUID &uuid);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
lldb_private::Section *GetMachHeaderSection();
lldb::addr_t CalculateSectionLoadAddressForMemoryImage(
lldb::addr_t mach_header_load_address,
const lldb_private::Section *mach_header_section,
const lldb_private::Section *section);
lldb_private::UUID
GetSharedCacheUUID(lldb_private::FileSpec dyld_shared_cache,
const lldb::ByteOrder byte_order,
const uint32_t addr_byte_size);
size_t ParseSymtab();
ObjectFileMachO: split CreateSections mega-function into more manageable chunks Summary: In an effort to understand the function's operation, I've split it into logical pieces. Parsing of a single segment is moved to a separate function (and the parsing state that is carried from one segment to another is explicitly captured in the SegmentParsingContext object). I've also extracted some pieces of code which were already standalone (validation of the segment load command, determining the section type, determining segment permissions) into separate functions. Parsing of a single section within the segment should probably also be a separate function, but I've left that for a separate patch. This patch is intended to be NFC. Reviewers: clayborg, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D44074 llvm-svn: 326791
2018-03-06 13:53:26 +00:00
typedef lldb_private::RangeArray<uint32_t, uint32_t, 8> EncryptedFileRanges;
EncryptedFileRanges GetEncryptedFileRanges();
struct SegmentParsingContext;
void ProcessDysymtabCommand(const llvm::MachO::load_command &load_cmd,
lldb::offset_t offset);
void ProcessSegmentCommand(const llvm::MachO::load_command &load_cmd,
lldb::offset_t offset, uint32_t cmd_idx,
SegmentParsingContext &context);
void SanitizeSegmentCommand(llvm::MachO::segment_command_64 &seg_cmd,
uint32_t cmd_idx);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
llvm::MachO::mach_header m_header;
static const lldb_private::ConstString &GetSegmentNameTEXT();
static const lldb_private::ConstString &GetSegmentNameDATA();
static const lldb_private::ConstString &GetSegmentNameDATA_DIRTY();
static const lldb_private::ConstString &GetSegmentNameDATA_CONST();
static const lldb_private::ConstString &GetSegmentNameOBJC();
static const lldb_private::ConstString &GetSegmentNameLINKEDIT();
static const lldb_private::ConstString &GetSectionNameEHFrame();
llvm::MachO::dysymtab_command m_dysymtab;
std::vector<llvm::MachO::segment_command_64> m_mach_segments;
std::vector<llvm::MachO::section_64> m_mach_sections;
Use llvm::VersionTuple instead of manual version marshalling Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
2018-06-18 15:02:23 +00:00
llvm::Optional<llvm::VersionTuple> m_min_os_version;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-06 20:57:50 +00:00
std::vector<uint32_t> m_sdk_versions;
typedef lldb_private::RangeVector<uint32_t, uint32_t> FileRangeArray;
lldb_private::Address m_entry_point_address;
FileRangeArray m_thread_context_offsets;
bool m_thread_context_offsets_valid;
lldb_private::FileSpecList m_reexported_dylibs;
bool m_allow_assembly_emulation_unwind_plans;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-08 16:52:24 +00:00
};
Fix Clang-tidy modernize-use-override warnings in source/Plugins/ObjectContainer and ObjectFile; other minor fixes. llvm-svn: 251119
2015-10-23 16:56:07 +00:00
#endif // liblldb_ObjectFileMachO_h_
Reference in New Issue Copy Permalink