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

532 lines
19 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;
Prune trailing whitespaces in comment lines. llvm-svn: 249285
2015-10-05 06:43:57 +02:00
/// MachORebaseEntry encapsulates the current state in the decompression of
[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
/// 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();
Reformat blank lines. llvm-svn: 249284
2015-10-05 06:43:48 +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
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
[Object] Make MachOObjectFile's constructor private, provide a static create method instead. This is not quite a named constructor: Construction may fail, and MachOObjectFiles are usually passed by unique_ptr anyway, so create returns an Expected<std::unique_ptr<MachOObjectFile>>. llvm-svn: 264469
2016-03-25 22:59:14 +01:00
static Expected<std::unique_ptr<MachOObjectFile>>
nother additional error check for an invalid Mach-O file when contained in a Mach-O universal file and the cputypes in both headers don’t match. llvm-svn: 285026
2016-10-24 23:15:11 +02:00
create(MemoryBufferRef Object, bool IsLittleEndian, bool Is64Bits,
uint32_t UniversalCputype = 0, uint32_t UniversalIndex = 0);
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;
Thread Expected<...> up from libObject’s getName() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 266919
2016-04-20 23:24:34 +02:00
Expected<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.
Add a checkSymbolTable() method to the MachOObjectFile class. The philosophy of the error checking in libObject for Mach-O files is that the constructor will check the load commands so for their tables the offsets and sizes are properly contained in the file. But there is no checking of the entries of any of the tables. For the contents of the tables themselves the methods accessing the contents of the entries return errors as needed. In some cases this however makes it difficult or cumbersome to produce a good error message which would include the tool name, file name, archive member, and name of the architecture of a slice of a universal file the error occurred in. So idea is that there will be a method to check a table which can be called up front before using it allowing a good error message to be produced before a table is used. And if only verification of the Mach-O file and its tables are wanted a new possible method checkAllTables() could be added to call all of the methods to check all the tables at some time when such methods exist. The checkSymbolTable() is the first of such methods to check one of the Mach-O file tables. This method initially will used in llvm-objdump’s DisassembleMachO() routine before it gets the section and symbol information. As if there are problems with the symbol table currently the error is first encountered by the bool operator() in the SymbolSorter() struct which passed to std::sort(). In this case there is no context as to the file name the symbol which results a poor error message: LLVM ERROR: truncated or malformed object (bad string index: 22 for symbol at index 1) with the added call to the checkSymbolTable() method the error message includes the tool name and file name: llvm-objdump: 'macho-invalid-symbol-strx': truncated or malformed object (bad string table index: 22 past the end of string table, for symbol at index 1) llvm-svn: 286887
2016-11-14 21:57:04 +01:00
Error checkSymbolTable() 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
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
Thread Expected<...> up from libObject’s getSymbolAddress() for symbols to allow a good error message to be produced. This is nearly the last libObject interface that used ErrorOr and the last one that appears in llvm/include/llvm/Object/MachO.h . For Mach-O objects this is just a clean up because it’s version of getSymbolAddress() can’t return an error. I will leave it to the experts on COFF and ELF to actually add meaning full error messages in their tests if they wish. And also leave it to these experts to change the last two ErrorOr interfaces in llvm/include/llvm/Object/ObjectFile.h for createCOFFObjectFile() and createELFObjectFile() if they wish. Since there are no test cases for COFF and ELF error cases with respect to getSymbolAddress() in the test suite this is no functional change (NFC). llvm-svn: 273701
2016-06-24 20:24:42 +02:00
Expected<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;
Thread Expected<...> up from libObject’s getType() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: "// TODO: Actually report errors helpfully" and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
2016-05-02 22:28:12 +02:00
Expected<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;
Thread Expected<...> up from libObject’s getType() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s section index is more than the number of sections. The existing test case in test/Object/macho-invalid.test for macho-invalid-section-index-getSectionRawName now reports the error with the message indicating that a symbol at a specific index has a bad section index and that bad section index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: "// TODO: Actually report errors helpfully" and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. llvm-svn: 268298
2016-05-02 22:28:12 +02:00
Expected<section_iterator> getSymbolSection(DataRefImpl Symb) 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;
Recommit r270547 ([llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style.) Fix was: 1) Had to regenerate dwarfdump-test-zlib.elf-x86-64, dwarfdump-test-zlib-gnu.elf-x86-64 (because llvm-symbolizer-zlib.test uses that inputs for its purposes and failed). 2) Updated llvm-symbolizer-zlib.test (updated used call function address to match new files + added one more check for newly created dwarfdump-test-zlib-gnu.elf-x86-64 binary input). 3) Updated comment in dwarfdump-test-zlib.cc. Original commit message: [llvm-dwarfdump] - Teach dwarfdump to decompress debug sections in zlib style. Before this llvm-dwarfdump only recognized zlib-gnu compression style of headers, this patch adds support for zlib style. It looks reasonable to support both styles for dumping, even if we are not going to suport generating of deprecated gnu one. Differential revision: http://reviews.llvm.org/D20470 llvm-svn: 270557
2016-05-24 14:48:46 +02:00
bool isSectionCompressed(DataRefImpl Sec) 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
bool isSectionText(DataRefImpl Sec) const override;
bool isSectionData(DataRefImpl Sec) const override;
bool isSectionBSS(DataRefImpl Sec) const override;
bool isSectionVirtual(DataRefImpl Sec) const override;
Rename embedded bitcode section in MachO Summary: Rename the section embeds bitcode from ".llvmbc,.llvmbc" to "__LLVM,__bitcode". The new name matches MachO section naming convention. Reviewers: rafael, pcc Subscribers: davide, llvm-commits, joker.eph Differential Revision: http://reviews.llvm.org/D17388 llvm-svn: 262245
2016-02-29 20:40:10 +01:00
bool isSectionBitcode(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;
Thread Expected<...> up from libObject’s getName() for symbols to allow llvm-objdump to produce a good error message. Produce another specific error message for a malformed Mach-O file when a symbol’s string index is past the end of the string table. The existing test case in test/Object/macho-invalid.test for macho-invalid-symbol-name-past-eof now reports the error with the message indicating that a symbol at a specific index has a bad sting index and that bad string index value. Again converting interfaces to Expected<> from ErrorOr<> does involve touching a number of places. Where the existing code reported the error with a string message or an error code it was converted to do the same. There is some code for this that could be factored into a routine but I would like to leave that for the code owners post-commit to do as they want for handling an llvm::Error. An example of how this could be done is shown in the diff in lib/ExecutionEngine/RuntimeDyld/RuntimeDyldImpl.h which had a Check() routine already for std::error_code so I added one like it for llvm::Error . Also there some were bugs in the existing code that did not deal with the old ErrorOr<> return values.  So now with Expected<> since they must be checked and the error handled, I added a TODO and a comment: “// TODO: Actually report errors helpfully” and a call something like consumeError(NameOrErr.takeError()) so the buggy code will not crash since needed to deal with the Error. Note there fixes needed to lld that goes along with this that I will commit right after this. So expect lld not to built after this commit and before the next one. llvm-svn: 266919
2016-04-20 23:24:34 +02:00
uint64_t getSymbolIndex(DataRefImpl Symb) const;
[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
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;
[llvm-objdump] Support detection of feature bits from the object and implement this for Mips. Summary: The Mips implementation only covers the feature bits described by the ELF e_flags so far. Mips stores additional feature bits such as MSA in the .MIPS.abiflags section. Also fixed a small bug this revealed where microMIPS wouldn't add the EF_MIPS_MICROMIPS flag when using -filetype=obj. Reviewers: echristo, rafael Subscribers: rafael, mehdi_amini, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21125 llvm-svn: 272880
2016-06-16 11:17:03 +02:00
SubtargetFeatures getFeatures() const override { return SubtargetFeatures(); }
MachO: remove weird ARM/Thumb interface from MachOObjectFile Only one consumer (llvm-objdump) actually cared about the fact that there were two triples. Others were actively working around the fact that the Triple returned by getArch might have been invalid. As for llvm-objdump, it needs to be acutely aware of both Triples anyway, so being generic in the exposed API is no benefit. Also rename the version of getArch returning a Triple. Users were having to pass an unwanted nullptr to disambiguate the two, which was nasty. The only functional change here is that armv7m and armv7em object files no longer crash llvm-objdump. llvm-svn: 267249
2016-04-23 01:21:13 +02:00
Triple getArchTriple(const char **McpuDefault = nullptr) 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);
MachO: remove weird ARM/Thumb interface from MachOObjectFile Only one consumer (llvm-objdump) actually cared about the fact that there were two triples. Others were actively working around the fact that the Triple returned by getArch might have been invalid. As for llvm-objdump, it needs to be acutely aware of both Triples anyway, so being generic in the exposed API is no benefit. Also rename the version of getArch returning a Triple. Users were having to pass an unwanted nullptr to disambiguate the two, which was nasty. The only functional change here is that armv7m and armv7em object files no longer crash llvm-objdump. llvm-svn: 267249
2016-04-23 01:21:13 +02:00
static Triple getArchTriple(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault = nullptr);
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
}
[MachO] Move trivial accessors to header. Requested by: Jim Grosbach. llvm-svn: 245963
2015-08-25 20:27:59 +02:00
static uint32_t
getVersionMinMajor(MachO::version_min_command &C, bool SDK) {
uint32_t VersionOrSDK = (SDK) ? C.sdk : C.version;
return (VersionOrSDK >> 16) & 0xffff;
}
static uint32_t
getVersionMinMinor(MachO::version_min_command &C, bool SDK) {
uint32_t VersionOrSDK = (SDK) ? C.sdk : C.version;
return (VersionOrSDK >> 8) & 0xff;
}
static uint32_t
getVersionMinUpdate(MachO::version_min_command &C, bool SDK) {
uint32_t VersionOrSDK = (SDK) ? C.sdk : C.version;
return VersionOrSDK & 0xff;
}
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:
[Object] Make MachOObjectFile's constructor private, provide a static create method instead. This is not quite a named constructor: Construction may fail, and MachOObjectFiles are usually passed by unique_ptr anyway, so create returns an Expected<std::unique_ptr<MachOObjectFile>>. llvm-svn: 264469
2016-03-25 22:59:14 +01:00
MachOObjectFile(MemoryBufferRef Object, bool IsLittleEndian, bool Is64Bits,
nother additional error check for an invalid Mach-O file when contained in a Mach-O universal file and the cputypes in both headers don’t match. llvm-svn: 285026
2016-10-24 23:15:11 +02:00
Error &Err, uint32_t UniversalCputype = 0,
uint32_t UniversalIndex = 0);
[Object] Make MachOObjectFile's constructor private, provide a static create method instead. This is not quite a named constructor: Construction may fail, and MachOObjectFiles are usually passed by unique_ptr anyway, so create returns an Expected<std::unique_ptr<MachOObjectFile>>. llvm-svn: 264469
2016-03-25 22:59:14 +01:00
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