6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-11-10 01:10:48 +00:00
Code Issues Projects Releases Wiki Activity
2e363ece75
llvm-6502/include/llvm/Object/MachO.h

421 lines
16 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141684 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 17:32:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141684 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 17:32:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178875 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-05 15:15:22 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-03 17:02:12 +00:00
#include "llvm/ADT/SmallVector.h"
Basic support for parsing Mach-O universal binaries in LLVMObject library git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184191 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-18 15:03:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@169133 91177308-0d34-0410-b5e6-96231b3b80d8
2012-12-03 17:02:12 +00:00
#include "llvm/Object/ObjectFile.h"
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141684 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 17:32:27 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206129 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-13 04:57:38 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-30 02:49:50 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217709 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-12 21:34:15 +00: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;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179440 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-13 01:45:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00:00
};
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179440 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-13 01:45:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216002 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 18:44:46 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179440 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-13 01:45:40 +00:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00:00
void moveSymbolNext(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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getSymbolName(DataRefImpl Symb,
StringRef &Res) 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 21:21:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getIndirectName(DataRefImpl Symb, StringRef &Res) const;
std::error_code getSymbolAddress(DataRefImpl Symb,
uint64_t &Res) const override;
std::error_code getSymbolAlignment(DataRefImpl Symb,
uint32_t &Res) const override;
std::error_code getSymbolSize(DataRefImpl Symb, uint64_t &Res) const override;
std::error_code getSymbolType(DataRefImpl Symb,
SymbolRef::Type &Res) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getSymbolSection(DataRefImpl Symb,
section_iterator &Res) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getSectionName(DataRefImpl Sec,
StringRef &Res) const override;
std::error_code getSectionAddress(DataRefImpl Sec,
uint64_t &Res) const override;
std::error_code getSectionSize(DataRefImpl Sec, uint64_t &Res) const override;
std::error_code getSectionContents(DataRefImpl Sec,
StringRef &Res) const override;
std::error_code getSectionAlignment(DataRefImpl Sec,
uint64_t &Res) const override;
std::error_code isSectionText(DataRefImpl Sec, bool &Res) const override;
std::error_code isSectionData(DataRefImpl Sec, bool &Res) const override;
std::error_code isSectionBSS(DataRefImpl Sec, bool &Res) const override;
std::error_code isSectionRequiredForExecution(DataRefImpl Sec,
bool &Res) const override;
std::error_code isSectionVirtual(DataRefImpl Sec, bool &Res) const override;
std::error_code isSectionZeroInit(DataRefImpl Sec, bool &Res) const override;
std::error_code isSectionReadOnlyData(DataRefImpl Sec,
bool &Res) const override;
std::error_code sectionContainsSymbol(DataRefImpl Sec, DataRefImpl Symb,
bool &Result) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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 use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getRelocationAddress(DataRefImpl Rel,
uint64_t &Res) const override;
std::error_code getRelocationOffset(DataRefImpl Rel,
uint64_t &Res) const override;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00:00
symbol_iterator getRelocationSymbol(DataRefImpl Rel) const override;
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
std::error_code getRelocationType(DataRefImpl Rel,
uint64_t &Res) const override;
std::error_code
getRelocationTypeName(DataRefImpl Rel,
SmallVectorImpl<char> &Result) const override;
std::error_code
getRelocationValueString(DataRefImpl Rel,
SmallVectorImpl<char> &Result) const override;
std::error_code getRelocationHidden(DataRefImpl Rel,
bool &Result) 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 21:21:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 21:21:57 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180009 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-22 10:27:32 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208635 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-12 21:39:59 +00:00
// MachO specific.
basic_symbol_iterator getSymbolByIndex(unsigned Index) const;
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00:00
Switch all uses of LLVM_OVERRIDE to just use 'override' directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202621 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-02 09:09:27 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215931 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 20:21:02 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191569 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-27 21:47:05 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
dice_iterator begin_dices() const;
dice_iterator end_dices() 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00:00
/// For use iterating over all exported symbols.
iterator_range<export_iterator> exports() const;
/// 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217709 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-12 21:34:15 +00: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);
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00:00
// MachO specific Info about relocations.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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;
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;
SectionRef getRelocationSection(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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00:00
// Walk load commands.
LoadCommandInfo getFirstLoadCommandInfo() const;
LoadCommandInfo getNextLoadCommandInfo(const LoadCommandInfo &L) const;
// MachO specific structures.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00:00
getLinkeditDataLoadCommand(const LoadCommandInfo &L) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00:00
getSegmentLoadCommand(const LoadCommandInfo &L) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00:00
getSegment64LoadCommand(const LoadCommandInfo &L) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
MachO::linker_options_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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00:00
getLinkerOptionsLoadCommand(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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@204190 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-18 22:09:05 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212043 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-30 14:40:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217172 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-04 16:54:47 +00: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;
MachO::source_version_command
getSourceVersionCommand(const LoadCommandInfo &L) const;
MachO::entry_point_command
getEntryPointCommand(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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00:00
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
MachO::any_relocation_info getRelocation(DataRefImpl Rel) const;
MachO::data_in_code_entry getDice(DataRefImpl Rel) const;
MachO::mach_header getHeader() const;
MachO::mach_header_64 getHeader64() const;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00:00
unsigned Index) const;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00: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;
Convert MachOObjectFile to a template. For now it is templated only on being 64 or 32 bits. I will add little/big endian next. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 21:21:57 +00:00
static StringRef guessLibraryShortName(StringRef Name, bool &isFramework,
StringRef &Suffix);
Basic support for parsing Mach-O universal binaries in LLVMObject library git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184191 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-18 15:03:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215931 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 20:21:02 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-08 16:30:17 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212054 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-30 18:45:23 +00:00
static Triple getHostArch();
Basic support for parsing Mach-O universal binaries in LLVMObject library git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184191 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-18 15:03:28 +00:00
llvm-objdump: don't print relocations in non-relocatable files. This matches the behavior of GNU objdump. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215844 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-17 19:09:37 +00:00
bool isRelocatableObject() const override;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00:00
private:
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213086 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-15 19:35:22 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213086 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-15 19:35:22 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 21:21:57 +00:00
LibraryList Libraries;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180624 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-26 20:07:33 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
const char *DataInCodeLoadCmd;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-30 00:20:14 +00:00
const char *DyldInfoLoadCmd;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179778 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 18:08:55 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 14:49:08 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-30 02:49:50 +00:00
inline void DiceRef::moveNext() {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200442 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-30 02:49:50 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.offset;
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
return object_error::success;
}
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.length;
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
return object_error::success;
}
Don't use 'using std::error_code' in include/llvm. This should make sure that most new uses use the std prefix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
const MachOObjectFile *MachOOF =
static_cast<const MachOObjectFile *>(OwningObject);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189728 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-01 04:28:48 +00:00
MachO::data_in_code_entry Dice = MachOOF->getDice(DicePimpl);
Result = Dice.kind;
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@183424 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-06 17:20:50 +00:00
return object_error::success;
}
inline DataRefImpl DiceRef::getRawDataRefImpl() const {
return DicePimpl;
}
inline const ObjectFile *DiceRef::getObjectFile() const {
return OwningObject;
}
Expose MachOObjectFile externally, like we do for COFF. First step in reducing the amount of special-purpose code needed for llvm-objdump. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141684 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 17:32:27 +00:00
}
}
#endif
Reference in New Issue Copy Permalink