RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-25 22:12:57 +02:00
Code Issues Projects Releases Wiki Activity
9584e54586
llvm-mirror/include/llvm/Object/MachO.h

508 lines
18 KiB
C
Raw Normal View History

Expose MachOObjectFile externally, like we do for COFF. First step in reducing the amount of special-purpose code needed for llvm-objdump. llvm-svn: 141684
2011-10-11 19:32:27 +02:00
//===- MachO.h - MachO object file implementation ---------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
// This file declares the MachOObjectFile class, which implement the ObjectFile
// interface for MachO files.
Expose MachOObjectFile externally, like we do for COFF. First step in reducing the amount of special-purpose code needed for llvm-objdump. llvm-svn: 141684
2011-10-11 19:32:27 +02:00
//
//===----------------------------------------------------------------------===//
#ifndef LLVM_OBJECT_MACHO_H
#define LLVM_OBJECT_MACHO_H
Don't fetch pointers from a InMemoryStruct. InMemoryStruct is extremely dangerous as it returns data from an internal buffer when the endiannes doesn't match. This should fix the tests on big endian hosts. llvm-svn: 178875
2013-04-05 17:15:22 +02:00
#include "llvm/ADT/ArrayRef.h"
Sort the #include lines for the include/... tree with the script. AKA: Recompile *ALL* the source code! This one went much better. No manual edits here. I spot-checked for silliness and grep-checked for really broken edits and everything seemed good. It all still compiles. Yell if you see something that looks goofy. llvm-svn: 169133
2012-12-03 18:02:12 +01:00
#include "llvm/ADT/SmallVector.h"
Basic support for parsing Mach-O universal binaries in LLVMObject library llvm-svn: 184191
2013-06-18 17:03:28 +02:00
#include "llvm/ADT/Triple.h"
Sort the #include lines for the include/... tree with the script. AKA: Recompile *ALL* the source code! This one went much better. No manual edits here. I spot-checked for silliness and grep-checked for really broken edits and everything seemed good. It all still compiles. Yell if you see something that looks goofy. llvm-svn: 169133
2012-12-03 18:02:12 +01:00
#include "llvm/Object/ObjectFile.h"
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
#include "llvm/Support/MachO.h"
Expose MachOObjectFile externally, like we do for COFF. First step in reducing the amount of special-purpose code needed for llvm-objdump. llvm-svn: 141684
2011-10-11 19:32:27 +02:00
namespace llvm {
namespace object {
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
/// DiceRef - This is a value type class that represents a single
/// data in code entry in the table in a Mach-O object file.
class DiceRef {
DataRefImpl DicePimpl;
const ObjectFile *OwningObject;
public:
[C++11] More 'nullptr' conversion or in some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 206129
2014-04-13 06:57:38 +02:00
DiceRef() : OwningObject(nullptr) { }
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
DiceRef(DataRefImpl DiceP, const ObjectFile *Owner);
bool operator==(const DiceRef &Other) const;
bool operator<(const DiceRef &Other) const;
Simplify the handling of iterators in ObjectFile. None of the object file formats reported error on iterator increment. In retrospect, that is not too surprising: no object format stores symbols or sections in a linked list or other structure that requires chasing pointers. As a consequence, all error checking can be done on begin() and end(). This reduces the text segment of bin/llvm-readobj in my machine from 521233 to 518526 bytes. llvm-svn: 200442
2014-01-30 03:49:50 +01:00
void moveNext();
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
std::error_code getOffset(uint32_t &Result) const;
std::error_code getLength(uint16_t &Result) const;
std::error_code getKind(uint16_t &Result) const;
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
DataRefImpl getRawDataRefImpl() const;
const ObjectFile *getObjectFile() const;
};
typedef content_iterator<DiceRef> dice_iterator;
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
/// ExportEntry encapsulates the current-state-of-the-walk used when doing a
/// non-recursive walk of the trie data structure. This allows you to iterate
/// across all exported symbols using:
/// for (const llvm::object::ExportEntry &AnExport : Obj->exports()) {
/// }
class ExportEntry {
public:
ExportEntry(ArrayRef<uint8_t> Trie);
StringRef name() const;
uint64_t flags() const;
uint64_t address() const;
uint64_t other() const;
StringRef otherName() const;
uint32_t nodeOffset() const;
bool operator==(const ExportEntry &) const;
void moveNext();
private:
friend class MachOObjectFile;
void moveToFirst();
void moveToEnd();
uint64_t readULEB128(const uint8_t *&p);
void pushDownUntilBottom();
void pushNode(uint64_t Offset);
// Represents a node in the mach-o exports trie.
struct NodeState {
NodeState(const uint8_t *Ptr);
const uint8_t *Start;
const uint8_t *Current;
uint64_t Flags;
uint64_t Address;
uint64_t Other;
const char *ImportName;
unsigned ChildCount;
unsigned NextChildIndex;
unsigned ParentStringLength;
bool IsExportNode;
};
ArrayRef<uint8_t> Trie;
SmallString<256> CumulativeString;
SmallVector<NodeState, 16> Stack;
bool Malformed;
bool Done;
};
typedef content_iterator<ExportEntry> export_iterator;
[llvm-objdump] support -rebase option for mach-o to dump rebasing info Similar to my previous -exports-trie option, the -rebase option dumps info from the LC_DYLD_INFO load command. The rebasing info is a list of the the locations that dyld needs to adjust if a mach-o image is not loaded at its preferred address. Since ASLR is now the default, images almost never load at their preferred address, and thus need to be rebased by dyld. llvm-svn: 217709
2014-09-12 23:34:15 +02:00
/// MachORebaseEntry encapsulates the current state in the decompression of
/// rebasing opcodes. This allows you to iterate through the compressed table of
/// rebasing using:
/// for (const llvm::object::MachORebaseEntry &Entry : Obj->rebaseTable()) {
/// }
class MachORebaseEntry {
public:
MachORebaseEntry(ArrayRef<uint8_t> opcodes, bool is64Bit);
uint32_t segmentIndex() const;
uint64_t segmentOffset() const;
StringRef typeName() const;
bool operator==(const MachORebaseEntry &) const;
void moveNext();
private:
friend class MachOObjectFile;
void moveToFirst();
void moveToEnd();
uint64_t readULEB128();
ArrayRef<uint8_t> Opcodes;
const uint8_t *Ptr;
uint64_t SegmentOffset;
uint32_t SegmentIndex;
uint64_t RemainingLoopCount;
uint64_t AdvanceAmount;
uint8_t RebaseType;
uint8_t PointerSize;
bool Malformed;
bool Done;
};
typedef content_iterator<MachORebaseEntry> rebase_iterator;
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command. The -bind option prints out symbolic references that dyld must resolve immediately. The -lazy-bind option prints out symbolc reference that are lazily resolved on first use. The -weak-bind option prints out information about symbols which dyld must try to coalesce across images. llvm-svn: 217853
2014-09-16 03:41:51 +02:00
/// MachOBindEntry encapsulates the current state in the decompression of
/// binding opcodes. This allows you to iterate through the compressed table of
/// bindings using:
/// for (const llvm::object::MachOBindEntry &Entry : Obj->bindTable()) {
/// }
class MachOBindEntry {
public:
enum class Kind { Regular, Lazy, Weak };
MachOBindEntry(ArrayRef<uint8_t> Opcodes, bool is64Bit, MachOBindEntry::Kind);
uint32_t segmentIndex() const;
uint64_t segmentOffset() const;
StringRef typeName() const;
StringRef symbolName() const;
uint32_t flags() const;
int64_t addend() const;
int ordinal() const;
bool operator==(const MachOBindEntry &) const;
void moveNext();
private:
friend class MachOObjectFile;
void moveToFirst();
void moveToEnd();
uint64_t readULEB128();
int64_t readSLEB128();
ArrayRef<uint8_t> Opcodes;
const uint8_t *Ptr;
uint64_t SegmentOffset;
uint32_t SegmentIndex;
StringRef SymbolName;
int Ordinal;
uint32_t Flags;
int64_t Addend;
uint64_t RemainingLoopCount;
uint64_t AdvanceAmount;
uint8_t BindType;
uint8_t PointerSize;
Kind TableKind;
bool Malformed;
bool Done;
};
typedef content_iterator<MachOBindEntry> bind_iterator;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
class MachOObjectFile : public ObjectFile {
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 03:45:40 +02:00
public:
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
struct LoadCommandInfo {
const char *Ptr; // Where in memory the load command is.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::load_command C; // The command itself.
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
};
[Object, MachO] Introduce MachOObjectFile::load_commands() range iterator. Summary: Now users don't have to manually deal with getFirstLoadCommandInfo() / getNextLoadCommandInfo(), calculate the number of load segments, etc. No functionality change. Test Plan: regression test suite Reviewers: rafael, lhames, loladiro Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10144 llvm-svn: 238983
2015-06-04 00:19:36 +02:00
typedef SmallVector<LoadCommandInfo, 4> LoadCommandList;
typedef LoadCommandList::const_iterator load_command_iterator;
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 03:45:40 +02:00
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-19 20:44:46 +02:00
MachOObjectFile(MemoryBufferRef Object, bool IsLittleEndian, bool Is64Bits,
std::error_code &EC);
Finish templating MachObjectFile over endianness. We are now able to handle big endian macho files in llvm-readobject. Thanks to David Fang for providing the object files. llvm-svn: 179440
2013-04-13 03:45:40 +02:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
void moveSymbolNext(DataRefImpl &Symb) const override;
Refactor duplicated code. NFC. llvm-svn: 240563
2015-06-24 20:14:41 +02:00
uint64_t getNValue(DataRefImpl Sym) const;
Return ErrorOr from SymbolRef::getName. This function can really fail since the string table offset can be out of bounds. Using ErrorOr makes sure the error is checked. Hopefully a lot of the boilerplate code in tools/* can go away once we have a diagnostic manager in Object. llvm-svn: 241297
2015-07-02 22:55:21 +02:00
ErrorOr<StringRef> getSymbolName(DataRefImpl Symb) const override;
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
// MachO specific.
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
std::error_code getIndirectName(DataRefImpl Symb, StringRef &Res) const;
Move three methods only used by MCJIT to MCJIT. These methods are only used by MCJIT and are very specific to it. In fact, they are also fairly specific to the fact that we have a dynamic linker of relocatable objects. llvm-svn: 223964
2014-12-10 21:46:55 +01:00
unsigned getSectionType(SectionRef Sec) const;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
Return ErrorOr from getSymbolAddress. It can fail trying to get the section on ELF and COFF. This makes sure the error is handled. llvm-svn: 241366
2015-07-03 20:19:00 +02:00
ErrorOr<uint64_t> getSymbolAddress(DataRefImpl Symb) const override;
Simplify interface of function that doesn't fail. llvm-svn: 238700
2015-06-01 01:52:50 +02:00
uint32_t getSymbolAlignment(DataRefImpl Symb) const override;
Change how symbol sizes are handled in lib/Object. COFF and MachO only define symbol sizes for common symbols. Reflect that in the class hierarchy by having a method for common symbols only in the base and a general one in ELF. This avoids the need of using a magic value for the size, which had a few problems * Most callers didn't check for it. * The ones that did could not tell the magic value from a file actually having that value. llvm-svn: 240529
2015-06-24 12:20:30 +02:00
uint64_t getCommonSymbolSizeImpl(DataRefImpl Symb) const override;
Simplify getSymbolType. This is still a really odd function. Most calls are in object format specific contexts and should probably be replaced with a more direct query, but at least now this is not too obnoxious to use. llvm-svn: 240777
2015-06-26 14:18:49 +02:00
SymbolRef::Type getSymbolType(DataRefImpl Symb) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
uint32_t getSymbolFlags(DataRefImpl Symb) const override;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
std::error_code getSymbolSection(DataRefImpl Symb,
section_iterator &Res) const override;
Make computeSymbolSizes never fail. On ELF that was already the case since getting the size of a symbol never fails. On MachO and COFF we could fail trying to get the section of a symbol. But we don't really need the section, just the section number to know if two symbols are in the same section or not. llvm-svn: 240580
2015-06-24 21:57:32 +02:00
unsigned getSymbolSectionID(SymbolRef Symb) const;
unsigned getSectionID(SectionRef Sec) const;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
void moveSectionNext(DataRefImpl &Sec) const override;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
std::error_code getSectionName(DataRefImpl Sec,
StringRef &Res) const override;
Remove bogus std::error_code returns form SectionRef. There are two methods in SectionRef that can fail: * getName: The index into the string table can be invalid. * getContents: The section might point to invalid contents. Every other method will always succeed and returning and std::error_code just complicates the code. For example, a section can have an invalid alignment, but if we are able to get to the section structure at all and create a SectionRef, we will always be able to read that invalid alignment. llvm-svn: 219314
2014-10-08 17:28:58 +02:00
uint64_t getSectionAddress(DataRefImpl Sec) const override;
uint64_t getSectionSize(DataRefImpl Sec) const override;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
std::error_code getSectionContents(DataRefImpl Sec,
StringRef &Res) const override;
Remove bogus std::error_code returns form SectionRef. There are two methods in SectionRef that can fail: * getName: The index into the string table can be invalid. * getContents: The section might point to invalid contents. Every other method will always succeed and returning and std::error_code just complicates the code. For example, a section can have an invalid alignment, but if we are able to get to the section structure at all and create a SectionRef, we will always be able to read that invalid alignment. llvm-svn: 219314
2014-10-08 17:28:58 +02:00
uint64_t getSectionAlignment(DataRefImpl Sec) const override;
bool isSectionText(DataRefImpl Sec) const override;
bool isSectionData(DataRefImpl Sec) const override;
bool isSectionBSS(DataRefImpl Sec) const override;
bool isSectionVirtual(DataRefImpl Sec) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
relocation_iterator section_rel_begin(DataRefImpl Sec) const override;
relocation_iterator section_rel_end(DataRefImpl Sec) const override;
void moveRelocationNext(DataRefImpl &Rel) const override;
Don't return error_code from function that never fails. llvm-svn: 241021
2015-06-30 01:29:12 +02:00
uint64_t getRelocationOffset(DataRefImpl Rel) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
symbol_iterator getRelocationSymbol(DataRefImpl Rel) const override;
Make getRelocationSection MachO only. There are 3 types of relocations on MachO * Scattered * Section based * Symbol based On ELF and COFF relocations are symbol based. We were in the strange situation that we abstracted over two of them. This makes section based relocations MachO only. llvm-svn: 240149
2015-06-19 19:54:28 +02:00
section_iterator getRelocationSection(DataRefImpl Rel) const;
Don't return error_code from a function that doesn't fail. llvm-svn: 241033
2015-06-30 03:53:01 +02:00
uint64_t getRelocationType(DataRefImpl Rel) const override;
Don't return error_code from a function that doesn't fail. llvm-svn: 241042
2015-06-30 06:08:37 +02:00
void getRelocationTypeName(DataRefImpl Rel,
SmallVectorImpl<char> &Result) const override;
Add RelocVisitor support for MachO This commit adds partial support for MachO relocations to RelocVisitor. A simple test case is added to show that relocations are indeed being applied and that using llvm-dwarfdump on MachO files no longer errors. Correctness is not yet tested, due to an unrelated bug in DebugInfo, which will be fixed with appropriate testcase in a followup commit. Differential Revision: http://reviews.llvm.org/D8148 llvm-svn: 238663
2015-05-30 21:44:53 +02:00
uint8_t getRelocationLength(DataRefImpl Rel) const;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
// MachO specific.
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
std::error_code getLibraryShortNameByIndex(unsigned Index, StringRef &) const;
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
Remove getRelocationAddress. Originally added in r139314. Back then it didn't actually get the address, it got whatever value the relocation used: address or offset. The values in different object formats are: * MachO: Always an offset. * COFF: Always an address, but when talking about the virtual address of sections it says: "for simplicity, compilers should set this to zero". * ELF: An offset for .o files and and address for .so files. In the case of the .so, the relocation in not linked to any section (sh_info is 0). We can't really compute an offset. Some API mappings would be: * Use getAddress for everything. It would be quite cumbersome. To compute the address elf has to follow sh_info, which can be corrupted and therefore the method has to return an ErrorOr. The address of the section is also the same for every relocation in a section, so we shouldn't have to check the error and fetch the value for every relocation. * Use a getValue and make it up to the user to know what it is getting. * Use a getOffset and: * Assert for dynamic ELF objects. That is a very peculiar case and it is probably fair to ask any tool that wants to support it to use ELF.h. The only tool we have that reads those (llvm-readobj) already does that. The only other use case I can think of is a dynamic linker. * Check that COFF .obj files have sections with zero virtual address spaces. If it turns out that some assembler/compiler produces these, we can change COFFObjectFile::getRelocationOffset to subtract it. Given COFF format, this can be done without the need for ErrorOr. The getRelocationAddress method was never implemented for COFF. It also had exactly one use in a very peculiar case: a shortcut for adding the section value to a pcrel reloc on MachO. Given that, I don't expect that there is any use out there of the C API. If that is not the case, let me know and I will add it back with the implementation inlined and do a proper deprecation. llvm-svn: 241450
2015-07-06 16:55:37 +02:00
section_iterator getRelocationRelocatedSection(relocation_iterator Rel) const;
Add the same todo about a command iterator interface into the other mach-o object file as well. TODO: One interface to rule them all. llvm-svn: 180009
2013-04-22 12:27:32 +02:00
// TODO: Would be useful to have an iterator based version
// of the load command interface too.
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
basic_symbol_iterator symbol_begin_impl() const override;
basic_symbol_iterator symbol_end_impl() const override;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
[RuntimeDyld] Add support for MachO __jump_table and __pointers sections, and SECTDIFF relocations on 32-bit x86. This fixes several of the MCJIT regression test failures that show up on 32-bit builds. <rdar://problem/16886294> llvm-svn: 208635
2014-05-12 23:39:59 +02:00
// MachO specific.
basic_symbol_iterator getSymbolByIndex(unsigned Index) const;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
section_iterator section_begin() const override;
section_iterator section_end() const override;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
uint8_t getBytesInAddress() const override;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. llvm-svn: 202621
2014-03-02 10:09:27 +01:00
StringRef getFileFormatName() const override;
unsigned getArch() const override;
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-18 22:21:02 +02:00
Triple getArch(const char **McpuDefault, Triple *ThumbTriple) const;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Object/COFF: Rename getXXX{Begin,End} -> xxx_{begin,end}. It is mentioned in the LLVM coding standard that _begin() and _end() suffixes should be used. llvm-svn: 191569
2013-09-27 23:47:05 +02:00
relocation_iterator section_rel_begin(unsigned Index) const;
relocation_iterator section_rel_end(unsigned Index) const;
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
dice_iterator begin_dices() const;
dice_iterator end_dices() const;
[Object, MachO] Introduce MachOObjectFile::load_commands() range iterator. Summary: Now users don't have to manually deal with getFirstLoadCommandInfo() / getNextLoadCommandInfo(), calculate the number of load segments, etc. No functionality change. Test Plan: regression test suite Reviewers: rafael, lhames, loladiro Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10144 llvm-svn: 238983
2015-06-04 00:19:36 +02:00
load_command_iterator begin_load_commands() const;
load_command_iterator end_load_commands() const;
iterator_range<load_command_iterator> load_commands() const;
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
/// For use iterating over all exported symbols.
iterator_range<export_iterator> exports() const;
[Object, MachO] Introduce MachOObjectFile::load_commands() range iterator. Summary: Now users don't have to manually deal with getFirstLoadCommandInfo() / getNextLoadCommandInfo(), calculate the number of load segments, etc. No functionality change. Test Plan: regression test suite Reviewers: rafael, lhames, loladiro Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10144 llvm-svn: 238983
2015-06-04 00:19:36 +02:00
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
/// For use examining a trie not in a MachOObjectFile.
static iterator_range<export_iterator> exports(ArrayRef<uint8_t> Trie);
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
[llvm-objdump] support -rebase option for mach-o to dump rebasing info Similar to my previous -exports-trie option, the -rebase option dumps info from the LC_DYLD_INFO load command. The rebasing info is a list of the the locations that dyld needs to adjust if a mach-o image is not loaded at its preferred address. Since ASLR is now the default, images almost never load at their preferred address, and thus need to be rebased by dyld. llvm-svn: 217709
2014-09-12 23:34:15 +02:00
/// For use iterating over all rebase table entries.
iterator_range<rebase_iterator> rebaseTable() const;
/// For use examining rebase opcodes not in a MachOObjectFile.
static iterator_range<rebase_iterator> rebaseTable(ArrayRef<uint8_t> Opcodes,
bool is64);
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command. The -bind option prints out symbolic references that dyld must resolve immediately. The -lazy-bind option prints out symbolc reference that are lazily resolved on first use. The -weak-bind option prints out information about symbols which dyld must try to coalesce across images. llvm-svn: 217853
2014-09-16 03:41:51 +02:00
/// For use iterating over all bind table entries.
iterator_range<bind_iterator> bindTable() const;
/// For use iterating over all lazy bind table entries.
iterator_range<bind_iterator> lazyBindTable() const;
/// For use iterating over all lazy bind table entries.
iterator_range<bind_iterator> weakBindTable() const;
/// For use examining bind opcodes not in a MachOObjectFile.
static iterator_range<bind_iterator> bindTable(ArrayRef<uint8_t> Opcodes,
bool is64,
MachOBindEntry::Kind);
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
// In a MachO file, sections have a segment name. This is used in the .o
// files. They have a single segment, but this field specifies which segment
// a section should be put in in the final object.
StringRef getSectionFinalSegmentName(DataRefImpl Sec) const;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
// Names are stored as 16 bytes. These returns the raw 16 bytes without
// interpreting them as a C string.
ArrayRef<char> getSectionRawName(DataRefImpl Sec) const;
ArrayRef<char> getSectionRawFinalSegmentName(DataRefImpl Sec) const;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
// MachO specific Info about relocations.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
bool isRelocationScattered(const MachO::any_relocation_info &RE) const;
unsigned getPlainRelocationSymbolNum(
const MachO::any_relocation_info &RE) const;
bool getPlainRelocationExternal(const MachO::any_relocation_info &RE) const;
bool getScatteredRelocationScattered(
const MachO::any_relocation_info &RE) const;
uint32_t getScatteredRelocationValue(
const MachO::any_relocation_info &RE) const;
Add the code and test cases for 32-bit Intel to llvm-objdump’s Mach-O symbolizer. llvm-svn: 221211
2014-11-04 01:43:16 +01:00
uint32_t getScatteredRelocationType(
const MachO::any_relocation_info &RE) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
unsigned getAnyRelocationAddress(const MachO::any_relocation_info &RE) const;
unsigned getAnyRelocationPCRel(const MachO::any_relocation_info &RE) const;
unsigned getAnyRelocationLength(const MachO::any_relocation_info &RE) const;
unsigned getAnyRelocationType(const MachO::any_relocation_info &RE) const;
Make it easier to use DwarfContext with MCJIT Summary: This supersedes http://reviews.llvm.org/D4010, hopefully properly dealing with the JIT case and also adds an actual test case. DwarfContext was basically already usable for the JIT (and back when we were overwriting ELF files it actually worked out of the box by accident), but in order to resolve relocations correctly it needs to know the load address of the section. Rather than trying to get this out of the ObjectFile or requiring the user to create a new ObjectFile just to get some debug info, this adds the capability to pass in that info directly. As part of this I separated out part of the LoadedObjectInfo struct from RuntimeDyld, since it is now required at a higher layer. Reviewers: lhames, echristo Reviewed By: echristo Subscribers: vtjnash, friss, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D6961 llvm-svn: 237961
2015-05-21 23:24:32 +02:00
SectionRef getAnyRelocationSection(const MachO::any_relocation_info &RE) const;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
// MachO specific structures.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::section getSection(DataRefImpl DRI) const;
MachO::section_64 getSection64(DataRefImpl DRI) const;
MachO::section getSection(const LoadCommandInfo &L, unsigned Index) const;
MachO::section_64 getSection64(const LoadCommandInfo &L,unsigned Index) const;
MachO::nlist getSymbolTableEntry(DataRefImpl DRI) const;
MachO::nlist_64 getSymbol64TableEntry(DataRefImpl DRI) const;
MachO::linkedit_data_command
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
getLinkeditDataLoadCommand(const LoadCommandInfo &L) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::segment_command
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
getSegmentLoadCommand(const LoadCommandInfo &L) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::segment_command_64
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
getSegment64LoadCommand(const LoadCommandInfo &L) const;
Add printing the LC_LINKER_OPTION load command with llvm-objdump’s -private-headers. Also corrected the name of the load command to not end in an ’S’ as well as corrected the name of the MachO::linker_option_command struct and other places that had the word option as plural which did not match the Mac OS X headers. llvm-svn: 224485
2014-12-18 01:53:40 +01:00
MachO::linker_option_command
getLinkerOptionLoadCommand(const LoadCommandInfo &L) const;
Darwin: Add assembler directives to create version-min load commands. Allow object files to be tagged with a version-min load command for iOS or MacOSX. Teach macho-dump to understand the version-min load commands for testcases. rdar://11337778 llvm-svn: 204190
2014-03-18 23:09:05 +01:00
MachO::version_min_command
getVersionMinLoadCommand(const LoadCommandInfo &L) const;
macho-dump: add code to print LC_ID_DYLIB load commands. I want to check them in lld. llvm-svn: 212043
2014-06-30 16:40:57 +02:00
MachO::dylib_command
getDylibIDLoadCommand(const LoadCommandInfo &L) const;
Adds the next bit of support for llvm-objdump’s -private-headers for executable Mach-O files. This adds the printing of more load commands, so that the normal load commands in a typical X86 Mach-O executable can all be printed. llvm-svn: 217172
2014-09-04 18:54:47 +02:00
MachO::dyld_info_command
getDyldInfoLoadCommand(const LoadCommandInfo &L) const;
MachO::dylinker_command
getDylinkerCommand(const LoadCommandInfo &L) const;
MachO::uuid_command
getUuidCommand(const LoadCommandInfo &L) const;
Add mach-o LC_RPATH support to llvm-objdump Summary: Add rpath load command support in Mach-O object and update llvm-objdump to use it. Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6512 llvm-svn: 223343
2014-12-04 08:37:02 +01:00
MachO::rpath_command
getRpathCommand(const LoadCommandInfo &L) const;
Adds the next bit of support for llvm-objdump’s -private-headers for executable Mach-O files. This adds the printing of more load commands, so that the normal load commands in a typical X86 Mach-O executable can all be printed. llvm-svn: 217172
2014-09-04 18:54:47 +02:00
MachO::source_version_command
getSourceVersionCommand(const LoadCommandInfo &L) const;
MachO::entry_point_command
getEntryPointCommand(const LoadCommandInfo &L) const;
Add printing the LC_ENCRYPTION_INFO load command with llvm-objdump’s -private-headers. llvm-svn: 224390
2014-12-17 00:25:52 +01:00
MachO::encryption_info_command
getEncryptionInfoCommand(const LoadCommandInfo &L) const;
Add printing the LC_ENCRYPTION_INFO_64 load command with llvm-objdump’s -private-headers and add tests for the two AArch64 binaries. llvm-svn: 224400
2014-12-17 02:01:30 +01:00
MachO::encryption_info_command_64
getEncryptionInfoCommand64(const LoadCommandInfo &L) const;
Add printing the LC_SUB_FRAMEWORK load command with llvm-objdump’s -private-headers. llvm-svn: 224534
2014-12-18 20:24:35 +01:00
MachO::sub_framework_command
getSubFrameworkCommand(const LoadCommandInfo &L) const;
Add printing the LC_SUB_UMBRELLA load command with llvm-objdump’s -private-headers. llvm-svn: 224548
2014-12-19 00:13:26 +01:00
MachO::sub_umbrella_command
getSubUmbrellaCommand(const LoadCommandInfo &L) const;
Add printing the LC_SUB_LIBRARY load command with llvm-objdump’s -private-headers. llvm-svn: 224607
2014-12-19 20:48:16 +01:00
MachO::sub_library_command
getSubLibraryCommand(const LoadCommandInfo &L) const;
Add printing the LC_SUB_CLIENT load command with llvm-objdump’s -private-headers. llvm-svn: 224616
2014-12-19 22:06:24 +01:00
MachO::sub_client_command
getSubClientCommand(const LoadCommandInfo &L) const;
Add printing the LC_ROUTINES load commands with llvm-objdump’s -private-headers. llvm-svn: 224627
2014-12-19 23:25:22 +01:00
MachO::routines_command
getRoutinesCommand(const LoadCommandInfo &L) const;
MachO::routines_command_64
getRoutinesCommand64(const LoadCommandInfo &L) const;
Add printing the LC_THREAD load commands with llvm-objdump’s -private-headers. llvm-svn: 224792
2014-12-23 23:56:39 +01:00
MachO::thread_command
getThreadCommand(const LoadCommandInfo &L) const;
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::any_relocation_info getRelocation(DataRefImpl Rel) const;
MachO::data_in_code_entry getDice(DataRefImpl Rel) const;
[Object, MachO] Cache parsed MachO header in MachOObjectFile. NFC. Summary: Avoid parsing object file each time MachOObjectFile::getHeader() is called. Instead, cache the header in MachOObjectFile constructor, where it's parsed anyway. In future, we must avoid constructing the object at all if the header can't be parsed. Test Plan: regression test suite. Reviewers: rafael Subscribers: llvm-commits llvm-svn: 239075
2015-06-04 21:22:03 +02:00
const MachO::mach_header &getHeader() const;
const MachO::mach_header_64 &getHeader64() const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
uint32_t
getIndirectSymbolTableEntry(const MachO::dysymtab_command &DLC,
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
unsigned Index) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::data_in_code_entry getDataInCodeTableEntry(uint32_t DataOffset,
unsigned Index) const;
MachO::symtab_command getSymtabLoadCommand() const;
MachO::dysymtab_command getDysymtabLoadCommand() const;
MachO::linkedit_data_command getDataInCodeLoadCommand() const;
dd the option, -link-opt-hints to llvm-objdump used with -macho to print the Mach-O AArch64 linker optimization hints for ADRP code optimization. llvm-svn: 227246
2015-01-27 22:28:24 +01:00
MachO::linkedit_data_command getLinkOptHintsLoadCommand() const;
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
ArrayRef<uint8_t> getDyldInfoRebaseOpcodes() const;
ArrayRef<uint8_t> getDyldInfoBindOpcodes() const;
ArrayRef<uint8_t> getDyldInfoWeakBindOpcodes() const;
ArrayRef<uint8_t> getDyldInfoLazyBindOpcodes() const;
ArrayRef<uint8_t> getDyldInfoExportsTrie() const;
Add MachOObjectFile::getUuid() This CL introduces MachOObjectFile::getUuid(). This function returns an ArrayRef to the object file's UUID, or an empty ArrayRef if the object file doesn't contain an LC_UUID load command. The new function is gonna be used by llvm-symbolizer. llvm-svn: 219866
2014-10-16 01:35:45 +02:00
ArrayRef<uint8_t> getUuid() const;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
StringRef getStringTableData() const;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
bool is64Bit() const;
void ReadULEB128s(uint64_t Index, SmallVectorImpl<uint64_t> &Out) const;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
static StringRef guessLibraryShortName(StringRef Name, bool &isFramework,
StringRef &Suffix);
Basic support for parsing Mach-O universal binaries in LLVMObject library llvm-svn: 184191
2013-06-18 17:03:28 +02:00
static Triple::ArchType getArch(uint32_t CPUType);
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-18 22:21:02 +02:00
static Triple getArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault = nullptr);
static Triple getThumbArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault = nullptr);
static Triple getArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault, Triple *ThumbTriple);
Use a simpler predicate. NFC. llvm-svn: 215218
2014-08-08 18:30:17 +02:00
static bool isValidArch(StringRef ArchFlag);
Add the -arch flag support to llvm-nm to select the slice out of a Mach-O universal file. This also includes support for -arch all, selecting the host architecture by default from a universal file and checking if -arch is used with a standard Mach-O it matches that architecture. llvm-svn: 212054
2014-06-30 20:45:23 +02:00
static Triple getHostArch();
Basic support for parsing Mach-O universal binaries in LLVMObject library llvm-svn: 184191
2013-06-18 17:03:28 +02:00
llvm-objdump: don't print relocations in non-relocatable files. This matches the behavior of GNU objdump. llvm-svn: 215844
2014-08-17 21:09:37 +02:00
bool isRelocatableObject() const override;
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command. The -bind option prints out symbolic references that dyld must resolve immediately. The -lazy-bind option prints out symbolc reference that are lazily resolved on first use. The -weak-bind option prints out information about symbols which dyld must try to coalesce across images. llvm-svn: 217853
2014-09-16 03:41:51 +02:00
bool hasPageZeroSegment() const { return HasPageZeroSegment; }
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
static bool classof(const Binary *v) {
return v->isMachO();
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
}
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
private:
Delete UnknownAddress. It is a perfectly valid symbol value. getSymbolValue now returns a value that in convenient for most callers: * 0 for undefined * symbol size for common symbols * offset/address for symbols the rest Code that needs something more specific can check getSymbolFlags. llvm-svn: 241605
2015-07-07 19:12:59 +02:00
uint64_t getSymbolValueImpl(DataRefImpl Symb) const override;
[Object, MachO] Fixup for r239075: use union to store mach_header and mach_header_64. llvm-svn: 239110
2015-06-05 00:49:55 +02:00
union {
MachO::mach_header_64 Header64;
MachO::mach_header Header;
};
[RuntimeDyld] Revert r211652 - MachO object GDB registration support. The registration scheme used in r211652 violated the read-only contract of MemoryBuffer. This caused crashes in llvm-rtdyld where macho objects were backed by read-only mmap'd memory. llvm-svn: 213086
2014-07-15 21:35:22 +02:00
typedef SmallVector<const char*, 1> SectionList;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
SectionList Sections;
[RuntimeDyld] Revert r211652 - MachO object GDB registration support. The registration scheme used in r211652 violated the read-only contract of MemoryBuffer. This caused crashes in llvm-rtdyld where macho objects were backed by read-only mmap'd memory. llvm-svn: 213086
2014-07-15 21:35:22 +02:00
typedef SmallVector<const char*, 1> LibraryList;
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
LibraryList Libraries;
[Object, MachO] Introduce MachOObjectFile::load_commands() range iterator. Summary: Now users don't have to manually deal with getFirstLoadCommandInfo() / getNextLoadCommandInfo(), calculate the number of load segments, etc. No functionality change. Test Plan: regression test suite Reviewers: rafael, lhames, loladiro Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D10144 llvm-svn: 238983
2015-06-04 00:19:36 +02:00
LoadCommandList LoadCommands;
Add "-format darwin" to llvm-nm to be like darwin's nm(1) -m output. This is a first step in seeing if it is possible to make llvm-nm produce the same output as darwin's nm(1). Darwin's default format is bsd but its -m output prints the longer Mach-O specific details. For now I added the "-format darwin" to do this (whos name may need to change in the future). As there are other Mach-O specific flags to nm(1) which I'm hoping to add some how in the future. But I wanted to see if I could get the correct output for -m flag using llvm-nm and the libObject interfaces. I got this working but would love to hear what others think about this approach to getting object/format specific details printed with llvm-nm. llvm-svn: 210285
2014-06-05 23:21:57 +02:00
typedef SmallVector<StringRef, 1> LibraryShortName;
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
mutable LibraryShortName LibrariesShortNames;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
const char *SymtabLoadCmd;
Use llvm/Object/MachO.h in macho-dumper. Drop the old macho parser. For Mach-O there were 2 implementations for parsing object files. A standalone llvm/Object/MachOObject.h and llvm/Object/MachO.h which implements the generic interface in llvm/Object/ObjectFile.h. This patch adds the missing features to MachO.h, moves macho-dump to use MachO.h and removes ObjectFile.h. In addition to making sure that check-all is clean, I checked that the new version produces exactly the same output in all Mach-O files in a llvm+clang build directory (including executables and shared libraries). To test the performance, I ran macho-dump over all the files in a llvm+clang build directory again, but this time redirecting the output to /dev/null. Both the old and new versions take about 4.6 seconds (2.5 user) to finish. llvm-svn: 180624
2013-04-26 22:07:33 +02:00
const char *DysymtabLoadCmd;
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
const char *DataInCodeLoadCmd;
dd the option, -link-opt-hints to llvm-objdump used with -macho to print the Mach-O AArch64 linker optimization hints for ADRP code optimization. llvm-svn: 227246
2015-01-27 22:28:24 +01:00
const char *LinkOptHintsLoadCmd;
Object/llvm-objdump: allow dumping of mach-o exports trie MachOObjectFile in lib/Object currently has no support for parsing the rebase, binding, and export information from the LC_DYLD_INFO load command in final linked mach-o images. This patch adds support for parsing the exports trie data structure. It also adds an option to llvm-objdump to dump that export info. I did the exports parsing first because it is the hardest. The information is encoded in a trie structure, but the standard ObjectFile way to inspect content is through iterators. So I needed to make an iterator that would do a non-recursive walk through the trie and maintain the concatenation of edges needed for the current string prefix. I plan to add similar support in MachOObjectFile and llvm-objdump to parse/display the rebasing and binding info too. llvm-svn: 216808
2014-08-30 02:20:14 +02:00
const char *DyldInfoLoadCmd;
Add MachOObjectFile::getUuid() This CL introduces MachOObjectFile::getUuid(). This function returns an ArrayRef to the object file's UUID, or an empty ArrayRef if the object file doesn't contain an LC_UUID load command. The new function is gonna be used by llvm-symbolizer. llvm-svn: 219866
2014-10-16 01:35:45 +02:00
const char *UuidLoadCmd;
[llvm-objdump] for mach-o add -bind, -lazy-bind, and -weak-bind options This finishes the ability of llvm-objdump to print out all information from the LC_DYLD_INFO load command. The -bind option prints out symbolic references that dyld must resolve immediately. The -lazy-bind option prints out symbolc reference that are lazily resolved on first use. The -weak-bind option prints out information about symbols which dyld must try to coalesce across images. llvm-svn: 217853
2014-09-16 03:41:51 +02:00
bool HasPageZeroSegment;
At Jim Grosbach's request detemplate Object/MachO.h. We are still able to handle mixed endian objects by swapping one struct at a time. llvm-svn: 179778
2013-04-18 20:08:55 +02:00
};
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. llvm-svn: 179097
2013-04-09 16:49:08 +02:00
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
/// DiceRef
inline DiceRef::DiceRef(DataRefImpl DiceP, const ObjectFile *Owner)
: DicePimpl(DiceP) , OwningObject(Owner) {}
inline bool DiceRef::operator==(const DiceRef &Other) const {
return DicePimpl == Other.DicePimpl;
}
inline bool DiceRef::operator<(const DiceRef &Other) const {
return DicePimpl < Other.DicePimpl;
}
Simplify the handling of iterators in ObjectFile. None of the object file formats reported error on iterator increment. In retrospect, that is not too surprising: no object format stores symbols or sections in a linked list or other structure that requires chasing pointers. As a consequence, all error checking can be done on begin() and end(). This reduces the text segment of bin/llvm-readobj in my machine from 521233 to 518526 bytes. llvm-svn: 200442
2014-01-30 03:49:50 +01:00
inline void DiceRef::moveNext() {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
const MachO::data_in_code_entry *P =
Simplify the handling of iterators in ObjectFile. None of the object file formats reported error on iterator increment. In retrospect, that is not too surprising: no object format stores symbols or sections in a linked list or other structure that requires chasing pointers. As a consequence, all error checking can be done on begin() and end(). This reduces the text segment of bin/llvm-readobj in my machine from 521233 to 518526 bytes. llvm-svn: 200442
2014-01-30 03:49:50 +01:00
reinterpret_cast<const MachO::data_in_code_entry *>(DicePimpl.p);
DicePimpl.p = reinterpret_cast<uintptr_t>(P + 1);
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
}
// Since a Mach-O data in code reference, a DiceRef, can only be created when
// the OwningObject ObjectFile is a MachOObjectFile a static_cast<> is used for
// the methods that get the values of the fields of the reference.
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
inline std::error_code DiceRef::getOffset(uint32_t &Result) const {
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.offset;
Remove object_error::success and use std::error_code() instead make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
2015-06-09 17:20:42 +02:00
return std::error_code();
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
}
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
inline std::error_code DiceRef::getLength(uint16_t &Result) const {
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.length;
Remove object_error::success and use std::error_code() instead make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
2015-06-09 17:20:42 +02:00
return std::error_code();
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
}
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-06-12 23:46:39 +02:00
inline std::error_code DiceRef::getKind(uint16_t &Result) const {
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 06:28:48 +02:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.kind;
Remove object_error::success and use std::error_code() instead make_error_code(object_error) is slow because object::object_category() uses a ManagedStatic variable. But the real problem is that the function is called too frequently. This patch uses std::error_code() instead of object_error::success. In most cases, we return "success", so this patch reduces number of function calls to that function. http://reviews.llvm.org/D10333 llvm-svn: 239409
2015-06-09 17:20:42 +02:00
return std::error_code();
Teach llvm-objdump with the -macho parser how to use the data in code table from the LC_DATA_IN_CODE load command. And when disassembling print the data in code formatted for the kind of data it and not disassemble those bytes. I added the format specific functionality to the derived class MachOObjectFile since these tables only appears in Mach-O object files. This is my first attempt to modify the libObject stuff so if folks have better suggestions how to fit this in or suggestions on the implementation please let me know. rdar://11791371 llvm-svn: 183424
2013-06-06 19:20:50 +02:00
}
inline DataRefImpl DiceRef::getRawDataRefImpl() const {
return DicePimpl;
}
inline const ObjectFile *DiceRef::getObjectFile() const {
return OwningObject;
}
Revert r240137 (Fixed/added namespace ending comments using clang-tidy. NFC) Apparently, the style needs to be agreed upon first. llvm-svn: 240390
2015-06-23 11:49:53 +02:00
}
}
Expose MachOObjectFile externally, like we do for COFF. First step in reducing the amount of special-purpose code needed for llvm-objdump. llvm-svn: 141684
2011-10-11 19:32:27 +02:00
#endif
Reference in New Issue Copy Permalink