maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Object/MachOObjectFile.cpp

2357 lines
74 KiB
C++
Raw Normal View History

Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08:00
//===- MachOObjectFile.cpp - Mach-O object file binding ---------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
//
// This file defines the MachOObjectFile class, which binds the MachOObject
// class to the generic ObjectFile wrapper.
//
//===----------------------------------------------------------------------===//
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-12 01:32:27 +08:00
#include "llvm/Object/MachO.h"
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
#include "llvm/ADT/STLExtras.h"
Use a simpler predicate. NFC. llvm-svn: 215218
2014-08-09 00:30:17 +08:00
#include "llvm/ADT/StringSwitch.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/ADT/Triple.h"
Make MachOObjectFile independent from MachOObject. llvm-svn: 178998
2013-04-08 04:01:29 +08:00
#include "llvm/Support/DataExtractor.h"
[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-13 05:34:15 +08:00
#include "llvm/Support/Debug.h"
Add support for scattered relocations to the MachO relocatation pretty printer. llvm-svn: 143051
2011-10-27 04:42:54 +08:00
#include "llvm/Support/Format.h"
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-19 02:08:55 +08:00
#include "llvm/Support/Host.h"
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 08:20:14 +08:00
#include "llvm/Support/LEB128.h"
#include "llvm/Support/MachO.h"
Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08:00
#include "llvm/Support/MemoryBuffer.h"
Move #includes from .h to .cpp file. llvm-svn: 188852
2013-08-21 09:20:11 +08:00
#include "llvm/Support/raw_ostream.h"
Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08:00
#include <cctype>
#include <cstring>
#include <limits>
using namespace llvm;
using namespace object;
Namespace cleanup (no functional change) llvm-svn: 213478
2014-07-20 20:08:28 +08:00
namespace {
struct section_base {
char sectname[16];
char segname[16];
};
}
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-19 02:08:55 +08:00
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
template <typename T>
Namespace cleanup (no functional change) llvm-svn: 213478
2014-07-20 20:08:28 +08:00
static T getStruct(const MachOObjectFile *O, const char *P) {
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
// Don't read before the beginning or past the end of the file
if (P < O->getData().begin() || P + sizeof(T) > O->getData().end())
report_fatal_error("Malformed MachO file.");
refactor the struct byte swapping to a helper function. llvm-svn: 179851
2013-04-19 21:45:05 +08:00
T Cmd;
memcpy(&Cmd, P, sizeof(T));
if (O->isLittleEndian() != sys::IsLittleEndianHost)
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::swapStruct(Cmd);
refactor the struct byte swapping to a helper function. llvm-svn: 179851
2013-04-19 21:45:05 +08:00
return Cmd;
[Object] * Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile. * Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable. * Implement this new interface completely for ELF, leave stubs for COFF and MachO. * Add 'llvm-readobj' tool for dumping ObjectFile information. llvm-svn: 151785
2012-03-01 09:36:50 +08:00
}
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
template <typename SegmentCmd>
static uint32_t getSegmentLoadCommandNumSections(const SegmentCmd &S,
uint32_t Cmdsize) {
const unsigned SectionSize = sizeof(SegmentCmd);
if (S.nsects > std::numeric_limits<uint32_t>::max() / SectionSize ||
S.nsects * SectionSize > Cmdsize - sizeof(S))
report_fatal_error(
"Number of sections too large for size of load command.");
return S.nsects;
}
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-19 02:08:55 +08:00
static uint32_t
getSegmentLoadCommandNumSections(const MachOObjectFile *O,
const MachOObjectFile::LoadCommandInfo &L) {
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
if (O->is64Bit())
return getSegmentLoadCommandNumSections(O->getSegment64LoadCommand(L),
L.C.cmdsize);
return getSegmentLoadCommandNumSections(O->getSegmentLoadCommand(L),
L.C.cmdsize);
[Object] Add ObjectFile::getLoadName() for retrieving the soname/installname of a shared object. llvm-svn: 151845
2012-03-02 06:19:54 +08:00
}
[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 09:41:51 +08:00
static bool isPageZeroSegment(const MachOObjectFile *O,
const MachOObjectFile::LoadCommandInfo &L) {
if (O->is64Bit()) {
MachO::segment_command_64 S = O->getSegment64LoadCommand(L);
return StringRef("__PAGEZERO").equals(S.segname);
}
MachO::segment_command S = O->getSegmentLoadCommand(L);
return StringRef("__PAGEZERO").equals(S.segname);
}
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-27 04:07:33 +08:00
static const char *
getSectionPtr(const MachOObjectFile *O, MachOObjectFile::LoadCommandInfo L,
unsigned Sec) {
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-19 02:08:55 +08:00
uintptr_t CommandAddr = reinterpret_cast<uintptr_t>(L.Ptr);
Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08: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-19 02:08:55 +08:00
bool Is64 = O->is64Bit();
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
unsigned SegmentLoadSize = Is64 ? sizeof(MachO::segment_command_64) :
sizeof(MachO::segment_command);
unsigned SectionSize = Is64 ? sizeof(MachO::section_64) :
sizeof(MachO::section);
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-19 02:08:55 +08:00
uintptr_t SectionAddr = CommandAddr + SegmentLoadSize + Sec * SectionSize;
Revert "Fix the build broken by r189315." and "Move everything depending on Object/MachOFormat.h over to Support/MachO.h." This reverts commits r189319 and r189315. r189315 broke some tests on what I believe are big-endian platforms. llvm-svn: 189321
2013-08-27 13:38:30 +08:00
return reinterpret_cast<const char*>(SectionAddr);
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-19 02:08:55 +08:00
}
static const char *getPtr(const MachOObjectFile *O, size_t Offset) {
return O->getData().substr(Offset, 1).data();
}
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
static MachO::nlist_base
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-19 02:08:55 +08:00
getSymbolTableEntryBase(const MachOObjectFile *O, DataRefImpl DRI) {
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
const char *P = reinterpret_cast<const char *>(DRI.p);
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
return getStruct<MachO::nlist_base>(O, P);
Change relocation API to be per section. This time without breaking GCC. llvm-svn: 141385
2011-10-08 03:25:32 +08: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-19 02:08:55 +08:00
static StringRef parseSegmentOrSectionName(const char *P) {
Add a function to get the segment name of a section. On MachO, sections also have segment names. When a tool looking at a .o file prints a segment name, this is what they mean. In reality, a .o has only one anonymous, segment. This patch adds a MachO only function to fetch that segment name. I named it getSectionFinalSegmentName since the main use for the name seems to be inform the linker with segment this section should go to. The patch also changes MachOObjectFile::getSectionName to return just the section name instead of computing SegmentName,SectionName. The main difference from the previous patch is that it doesn't use InMemoryStruct. It is extremely dangerous: if the endians match it returns a pointer to the file buffer, if not, it returns a pointer to an internal buffer that is overwritten in the next API call. We should change all of this code to use support::detail::packed_endian_specific_integral like ELF, but since these functions only handle strings, they work with big and little endian machines as is. I have tested this by installing ubuntu 12.10 ppc on qemu, that is why it took so long :-) llvm-svn: 170838
2012-12-21 11:47:03 +08:00
if (P[15] == 0)
// Null terminated.
return P;
// Not null terminated, so this is a 16 char string.
return StringRef(P, 16);
}
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-19 02:08:55 +08:00
// Helper to advance a section or symbol iterator multiple increments at a time.
template<class T>
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 10:49:50 +08:00
static void advance(T &it, size_t Val) {
while (Val--)
++it;
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-19 02:08:55 +08:00
}
static unsigned getCPUType(const MachOObjectFile *O) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return O->getHeader().cputype;
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
static uint32_t
getPlainRelocationAddress(const MachO::any_relocation_info &RE) {
return RE.r_word0;
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-19 02:08:55 +08:00
}
static unsigned
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
getScatteredRelocationAddress(const MachO::any_relocation_info &RE) {
return RE.r_word0 & 0xffffff;
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-19 02:08:55 +08:00
}
static bool getPlainRelocationPCRel(const MachOObjectFile *O,
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) {
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-19 02:08:55 +08:00
if (O->isLittleEndian())
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return (RE.r_word1 >> 24) & 1;
return (RE.r_word1 >> 7) & 1;
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-19 02:08:55 +08:00
}
static bool
getScatteredRelocationPCRel(const MachOObjectFile *O,
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) {
return (RE.r_word0 >> 30) & 1;
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-19 02:08:55 +08:00
}
static unsigned getPlainRelocationLength(const MachOObjectFile *O,
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) {
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-19 02:08:55 +08:00
if (O->isLittleEndian())
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return (RE.r_word1 >> 25) & 3;
return (RE.r_word1 >> 5) & 3;
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-19 02:08:55 +08:00
}
static unsigned
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
getScatteredRelocationLength(const MachO::any_relocation_info &RE) {
return (RE.r_word0 >> 28) & 3;
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-19 02:08:55 +08:00
}
static unsigned getPlainRelocationType(const MachOObjectFile *O,
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) {
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-19 02:08:55 +08:00
if (O->isLittleEndian())
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return RE.r_word1 >> 28;
return RE.r_word1 & 0xf;
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-19 02:08:55 +08:00
}
static uint32_t getSectionFlags(const MachOObjectFile *O,
DataRefImpl Sec) {
if (O->is64Bit()) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 Sect = O->getSection64(Sec);
return Sect.flags;
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section Sect = O->getSection(Sec);
return Sect.flags;
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-19 02:08:55 +08:00
}
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
MachOObjectFile::MachOObjectFile(MemoryBufferRef Object, bool IsLittleEndian,
bool Is64bits, std::error_code &EC)
: ObjectFile(getMachOType(IsLittleEndian, Is64bits), Object),
[C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr. llvm-svn: 206252
2014-04-15 14:32:26 +08:00
SymtabLoadCmd(nullptr), DysymtabLoadCmd(nullptr),
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-28 05:28:24 +08:00
DataInCodeLoadCmd(nullptr), LinkOptHintsLoadCmd(nullptr),
DyldInfoLoadCmd(nullptr), UuidLoadCmd(nullptr),
HasPageZeroSegment(false) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint32_t LoadCommandCount = this->getHeader().ncmds;
Don't loop endlessly for MachO files with 0 ncmds llvm-svn: 225271
2015-01-07 01:08:26 +08:00
if (LoadCommandCount == 0)
return;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::LoadCommandType SegmentLoadType = is64Bit() ?
MachO::LC_SEGMENT_64 : MachO::LC_SEGMENT;
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-19 02:08:55 +08:00
MachOObjectFile::LoadCommandInfo Load = getFirstLoadCommandInfo();
Don't read one command past the end. Thanks to Evgeniy Stepanov for reporting this. It might be a good idea to add a command iterator abstraction to MachO.h, but this fixes the bug for now. llvm-svn: 179848
2013-04-19 19:36:47 +08:00
for (unsigned I = 0; ; ++I) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
if (Load.C.cmd == MachO::LC_SYMTAB) {
Object, Mach-O: Refactor and clean code up Don't assert if we can return an error code, reuse existing functionality like is64Bit(). llvm-svn: 221915
2014-11-14 03:48:56 +08:00
// Multiple symbol tables
if (SymtabLoadCmd) {
EC = object_error::parse_failed;
return;
}
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-19 02:08:55 +08:00
SymtabLoadCmd = Load.Ptr;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
} else if (Load.C.cmd == MachO::LC_DYSYMTAB) {
Object, Mach-O: Refactor and clean code up Don't assert if we can return an error code, reuse existing functionality like is64Bit(). llvm-svn: 221915
2014-11-14 03:48:56 +08:00
// Multiple dynamic symbol tables
if (DysymtabLoadCmd) {
EC = object_error::parse_failed;
return;
}
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-27 04:07:33 +08:00
DysymtabLoadCmd = Load.Ptr;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
} else if (Load.C.cmd == MachO::LC_DATA_IN_CODE) {
Object, Mach-O: Refactor and clean code up Don't assert if we can return an error code, reuse existing functionality like is64Bit(). llvm-svn: 221915
2014-11-14 03:48:56 +08:00
// Multiple data in code tables
if (DataInCodeLoadCmd) {
EC = object_error::parse_failed;
return;
}
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-07 01:20:50 +08:00
DataInCodeLoadCmd = Load.Ptr;
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-28 05:28:24 +08:00
} else if (Load.C.cmd == MachO::LC_LINKER_OPTIMIZATION_HINT) {
// Multiple linker optimization hint tables
if (LinkOptHintsLoadCmd) {
EC = object_error::parse_failed;
return;
}
LinkOptHintsLoadCmd = Load.Ptr;
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 08:20:14 +08:00
} else if (Load.C.cmd == MachO::LC_DYLD_INFO ||
Load.C.cmd == MachO::LC_DYLD_INFO_ONLY) {
Object, Mach-O: Refactor and clean code up Don't assert if we can return an error code, reuse existing functionality like is64Bit(). llvm-svn: 221915
2014-11-14 03:48:56 +08:00
// Multiple dyldinfo load commands
if (DyldInfoLoadCmd) {
EC = object_error::parse_failed;
return;
}
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 08:20:14 +08:00
DyldInfoLoadCmd = Load.Ptr;
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 07:35:45 +08:00
} else if (Load.C.cmd == MachO::LC_UUID) {
Object, Mach-O: Refactor and clean code up Don't assert if we can return an error code, reuse existing functionality like is64Bit(). llvm-svn: 221915
2014-11-14 03:48:56 +08:00
// Multiple UUID load commands
if (UuidLoadCmd) {
EC = object_error::parse_failed;
return;
}
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 07:35:45 +08:00
UuidLoadCmd = Load.Ptr;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
} else if (Load.C.cmd == SegmentLoadType) {
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
const unsigned SegmentLoadSize = this->is64Bit()
? sizeof(MachO::segment_command_64)
: sizeof(MachO::segment_command);
if (Load.C.cmdsize < SegmentLoadSize)
report_fatal_error("Segment load command size is too small.");
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-19 02:08:55 +08:00
uint32_t NumSections = getSegmentLoadCommandNumSections(this, Load);
for (unsigned J = 0; J < NumSections; ++J) {
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-27 04:07:33 +08:00
const char *Sec = getSectionPtr(this, Load, J);
Sections.push_back(Sec);
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-19 02:08:55 +08:00
}
[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 09:41:51 +08:00
if (isPageZeroSegment(this, Load))
HasPageZeroSegment = true;
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-06 05:21:57 +08:00
} else if (Load.C.cmd == MachO::LC_LOAD_DYLIB ||
Load.C.cmd == MachO::LC_LOAD_WEAK_DYLIB ||
Load.C.cmd == MachO::LC_LAZY_LOAD_DYLIB ||
Load.C.cmd == MachO::LC_REEXPORT_DYLIB ||
Load.C.cmd == MachO::LC_LOAD_UPWARD_DYLIB) {
Libraries.push_back(Load.Ptr);
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-19 02:08:55 +08:00
}
Don't read one command past the end. Thanks to Evgeniy Stepanov for reporting this. It might be a good idea to add a command iterator abstraction to MachO.h, but this fixes the bug for now. llvm-svn: 179848
2013-04-19 19:36:47 +08:00
if (I == LoadCommandCount - 1)
break;
else
Load = getNextLoadCommandInfo(Load);
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-19 02:08:55 +08:00
}
}
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 10:49:50 +08:00
void MachOObjectFile::moveSymbolNext(DataRefImpl &Symb) const {
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
unsigned SymbolTableEntrySize = is64Bit() ?
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
sizeof(MachO::nlist_64) :
sizeof(MachO::nlist);
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
Symb.p += SymbolTableEntrySize;
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-19 02:08:55 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSymbolName(DataRefImpl Symb,
StringRef &Res) 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-27 04:07:33 +08:00
StringRef StringTable = getStringTableData();
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::nlist_base Entry = getSymbolTableEntryBase(this, Symb);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const char *Start = &StringTable.data()[Entry.n_strx];
Fix edge case when Start overflowed in 32 bit mode llvm-svn: 226229
2015-01-16 07:50:44 +08:00
if (Start < getData().begin() || Start >= getData().end())
report_fatal_error(
"Symbol name entry points before beginning or past end of file.");
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-19 02:08:55 +08:00
Res = StringRef(Start);
return object_error::success;
}
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-11 04:46:55 +08:00
unsigned MachOObjectFile::getSectionType(SectionRef Sec) const {
DataRefImpl DRI = Sec.getRawDataRefImpl();
uint32_t Flags = getSectionFlags(this, DRI);
return Flags & MachO::SECTION_TYPE;
}
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-06 05:21:57 +08:00
// getIndirectName() returns the name of the alias'ed symbol who's string table
// index is in the n_value field.
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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getIndirectName(DataRefImpl Symb,
StringRef &Res) 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-06 05:21:57 +08:00
StringRef StringTable = getStringTableData();
uint64_t NValue;
if (is64Bit()) {
MachO::nlist_64 Entry = getSymbol64TableEntry(Symb);
NValue = Entry.n_value;
if ((Entry.n_type & MachO::N_TYPE) != MachO::N_INDR)
return object_error::parse_failed;
} else {
MachO::nlist Entry = getSymbolTableEntry(Symb);
NValue = Entry.n_value;
if ((Entry.n_type & MachO::N_TYPE) != MachO::N_INDR)
return object_error::parse_failed;
}
if (NValue >= StringTable.size())
return object_error::parse_failed;
const char *Start = &StringTable.data()[NValue];
Res = StringRef(Start);
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. llvm-svn: 210835
2014-06-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSymbolAddress(DataRefImpl Symb,
uint64_t &Res) 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-19 02:08:55 +08:00
if (is64Bit()) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::nlist_64 Entry = getSymbol64TableEntry(Symb);
Update MachOObjectFile::getSymbolAddress so it returns UnknownAddressOrSize for undefined symbols, so it matches what COFFObjectFile::getSymbolAddress does. This allows llvm-nm to print spaces instead of 0’s for the value of undefined symbols in Mach-O files. To make this change other uses of MachOObjectFile::getSymbolAddress are updated to handle when the Value is returned as UnknownAddressOrSize. Which is needed to keep two of the ExecutionEngine tests working for example. llvm-svn: 209253
2014-05-21 07:04:47 +08:00
if ((Entry.n_type & MachO::N_TYPE) == MachO::N_UNDF &&
Entry.n_value == 0)
Res = UnknownAddressOrSize;
else
Res = Entry.n_value;
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-19 02:08:55 +08:00
} else {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::nlist Entry = getSymbolTableEntry(Symb);
Update MachOObjectFile::getSymbolAddress so it returns UnknownAddressOrSize for undefined symbols, so it matches what COFFObjectFile::getSymbolAddress does. This allows llvm-nm to print spaces instead of 0’s for the value of undefined symbols in Mach-O files. To make this change other uses of MachOObjectFile::getSymbolAddress are updated to handle when the Value is returned as UnknownAddressOrSize. Which is needed to keep two of the ExecutionEngine tests working for example. llvm-svn: 209253
2014-05-21 07:04:47 +08:00
if ((Entry.n_type & MachO::N_TYPE) == MachO::N_UNDF &&
Entry.n_value == 0)
Res = UnknownAddressOrSize;
else
Res = Entry.n_value;
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-19 02:08:55 +08:00
}
return object_error::success;
}
Simplify interface of function that doesn't fail. llvm-svn: 238700
2015-06-01 07:52:50 +08:00
uint32_t MachOObjectFile::getSymbolAlignment(DataRefImpl DRI) const {
Simplify getSymbolFlags. None of the object formats require extra parsing to compute these flags, so the method cannot fail. llvm-svn: 200574
2014-02-01 04:57:12 +08:00
uint32_t flags = getSymbolFlags(DRI);
Add getSymbolAlignment to the ObjectFile interface. For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-30 06:24:22 +08:00
if (flags & SymbolRef::SF_Common) {
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::nlist_base Entry = getSymbolTableEntryBase(this, DRI);
Simplify interface of function that doesn't fail. llvm-svn: 238700
2015-06-01 07:52:50 +08:00
return 1 << MachO::GET_COMM_ALIGN(Entry.n_desc);
Add getSymbolAlignment to the ObjectFile interface. For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-30 06:24:22 +08:00
}
Simplify interface of function that doesn't fail. llvm-svn: 238700
2015-06-01 07:52:50 +08:00
return 0;
Add getSymbolAlignment to the ObjectFile interface. For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-30 06:24:22 +08:00
}
Simplify another function that doesn't fail. llvm-svn: 238703
2015-06-01 08:27:26 +08:00
uint64_t MachOObjectFile::getSymbolSize(DataRefImpl DRI) 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-19 02:08:55 +08:00
uint64_t Value;
getSymbolAddress(DRI, Value);
Stop inventing symbol sizes. MachO and COFF quite reasonably only define the size for common symbols. We used to try to figure out the "size" by computing the gap from one symbol to the next. This would not be correct in general, since a part of a section can belong to no visible symbol (padding, private globals). It was also really expensive, since we would walk every symbol to find the size of one. If a caller really wants this, it can sort all the symbols once and get all the gaps ("size") in O(n log n) instead of O(n^2). On MachO this also has the advantage of centralizing all the checks for an invalid n_sect. llvm-svn: 238028
2015-05-22 23:43:00 +08:00
uint32_t flags = getSymbolFlags(DRI);
if (flags & SymbolRef::SF_Common)
Simplify another function that doesn't fail. llvm-svn: 238703
2015-06-01 08:27:26 +08:00
return Value;
return UnknownAddressOrSize;
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-19 02:08:55 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSymbolType(DataRefImpl Symb,
SymbolRef::Type &Res) const {
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::nlist_base Entry = getSymbolTableEntryBase(this, Symb);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint8_t n_type = Entry.n_type;
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-19 02:08:55 +08:00
Res = SymbolRef::ST_Other;
// If this is a STAB debugging symbol, we can do nothing more.
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if (n_type & MachO::N_STAB) {
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-19 02:08:55 +08:00
Res = SymbolRef::ST_Debug;
return object_error::success;
}
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
switch (n_type & MachO::N_TYPE) {
case MachO::N_UNDF :
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-19 02:08:55 +08:00
Res = SymbolRef::ST_Unknown;
break;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case MachO::N_SECT :
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-19 02:08:55 +08:00
Res = SymbolRef::ST_Function;
break;
}
return object_error::success;
}
Simplify getSymbolFlags. None of the object formats require extra parsing to compute these flags, so the method cannot fail. llvm-svn: 200574
2014-02-01 04:57:12 +08:00
uint32_t MachOObjectFile::getSymbolFlags(DataRefImpl DRI) const {
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::nlist_base Entry = getSymbolTableEntryBase(this, DRI);
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-19 02:08:55 +08:00
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint8_t MachOType = Entry.n_type;
uint16_t MachOFlags = Entry.n_desc;
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-19 02:08:55 +08:00
Simplify getSymbolFlags. None of the object formats require extra parsing to compute these flags, so the method cannot fail. llvm-svn: 200574
2014-02-01 04:57:12 +08:00
uint32_t Result = SymbolRef::SF_None;
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-19 02:08:55 +08:00
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if ((MachOType & MachO::N_TYPE) == MachO::N_UNDF)
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-19 02:08:55 +08:00
Result |= SymbolRef::SF_Undefined;
MachO: support N_INDR aliases in assembly files. This makes LLVM create N_INDR aliases (to be resolved by the linker) when appropriate. rdar://problem/15125513 llvm-svn: 209894
2014-05-30 21:22:59 +08:00
if ((MachOType & MachO::N_TYPE) == MachO::N_INDR)
Result |= SymbolRef::SF_Indirect;
Fix llvm-nm to mach OS X's nm on some tests. There is still a long way to go for llvm-nm, but at least we now match nm's letter output in the cases we test for. llvm-svn: 193912
2013-11-02 13:03:24 +08:00
if (MachOType & MachO::N_STAB)
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-19 02:08:55 +08:00
Result |= SymbolRef::SF_FormatSpecific;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if (MachOType & MachO::N_EXT) {
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-19 02:08:55 +08:00
Result |= SymbolRef::SF_Global;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if ((MachOType & MachO::N_TYPE) == MachO::N_UNDF) {
Add getSymbolAlignment to the ObjectFile interface. For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-30 06:24:22 +08:00
uint64_t Value;
getSymbolAddress(DRI, Value);
Update MachOObjectFile::getSymbolAddress so it returns UnknownAddressOrSize for undefined symbols, so it matches what COFFObjectFile::getSymbolAddress does. This allows llvm-nm to print spaces instead of 0’s for the value of undefined symbols in Mach-O files. To make this change other uses of MachOObjectFile::getSymbolAddress are updated to handle when the Value is returned as UnknownAddressOrSize. Which is needed to keep two of the ExecutionEngine tests working for example. llvm-svn: 209253
2014-05-21 07:04:47 +08:00
if (Value && Value != UnknownAddressOrSize)
Add getSymbolAlignment to the ObjectFile interface. For regular object files this is only meaningful for common symbols. An object file format with direct support for atoms should be able to provide alignment information for all symbols. This replaces getCommonSymbolAlignment and fixes test-common-symbols-alignment.ll on darwin. This also includes a fix to MachOObjectFile::getSymbolFlags. It was marking undefined symbols as common (already tested by existing mcjit tests now that it is used). llvm-svn: 180736
2013-04-30 06:24:22 +08:00
Result |= SymbolRef::SF_Common;
}
[Object] Add SF_Exported flag. This flag will be set on all symbols that would be exported from a dylib if their containing object file were linked into one. No test case: No command line tools query this flag, and there are no Object unit tests. llvm-svn: 226217
2015-01-16 06:33:30 +08:00
if (!(MachOType & MachO::N_PEXT))
Result |= SymbolRef::SF_Exported;
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-19 02:08:55 +08:00
}
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if (MachOFlags & (MachO::N_WEAK_REF | MachO::N_WEAK_DEF))
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-19 02:08:55 +08:00
Result |= SymbolRef::SF_Weak;
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
if (MachOFlags & (MachO::N_ARM_THUMB_DEF))
Result |= SymbolRef::SF_Thumb;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
if ((MachOType & MachO::N_TYPE) == MachO::N_ABS)
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-19 02:08:55 +08:00
Result |= SymbolRef::SF_Absolute;
Simplify getSymbolFlags. None of the object formats require extra parsing to compute these flags, so the method cannot fail. llvm-svn: 200574
2014-02-01 04:57:12 +08:00
return Result;
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-19 02:08:55 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSymbolSection(DataRefImpl Symb,
section_iterator &Res) const {
extracting swapStruct into include/llvm/Support/MachO.h (no functional change) llvm-svn: 213361
2014-07-18 17:26:16 +08:00
MachO::nlist_base Entry = getSymbolTableEntryBase(this, Symb);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint8_t index = Entry.n_sect;
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-19 02:08:55 +08:00
if (index == 0) {
Change the begin and end methods in ObjectFile to match the style guide. llvm-svn: 201108
2014-02-11 04:24:04 +08:00
Res = section_end();
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-19 02:08:55 +08:00
} else {
DataRefImpl DRI;
DRI.d.a = index - 1;
Detect invalid section indexes when we first read them. We still detect the same errors, but now we do it earlier. llvm-svn: 238024
2015-05-22 22:59:27 +08:00
if (DRI.d.a >= Sections.size())
report_fatal_error("getSymbolSection: Invalid section index.");
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-19 02:08:55 +08:00
Res = section_iterator(SectionRef(DRI, this));
}
return object_error::success;
}
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 10:49:50 +08:00
void MachOObjectFile::moveSectionNext(DataRefImpl &Sec) 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-19 02:08:55 +08:00
Sec.d.a++;
}
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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSectionName(DataRefImpl Sec,
StringRef &Result) 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-19 02:08:55 +08:00
ArrayRef<char> Raw = getSectionRawName(Sec);
Result = parseSegmentOrSectionName(Raw.data());
return object_error::success;
}
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 23:28:58 +08:00
uint64_t MachOObjectFile::getSectionAddress(DataRefImpl Sec) const {
if (is64Bit())
return getSection64(Sec).addr;
return getSection(Sec).addr;
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-19 02:08:55 +08:00
}
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 23:28:58 +08:00
uint64_t MachOObjectFile::getSectionSize(DataRefImpl Sec) const {
if (is64Bit())
return getSection64(Sec).size;
return getSection(Sec).size;
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-19 02:08:55 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getSectionContents(DataRefImpl Sec,
StringRef &Res) 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-19 02:08:55 +08:00
uint32_t Offset;
uint64_t Size;
if (is64Bit()) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 Sect = getSection64(Sec);
Offset = Sect.offset;
Size = Sect.size;
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-19 02:08:55 +08:00
} else {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section Sect = getSection(Sec);
Offset = Sect.offset;
Size = Sect.size;
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-19 02:08:55 +08:00
}
Res = this->getData().substr(Offset, Size);
return object_error::success;
}
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 23:28:58 +08:00
uint64_t MachOObjectFile::getSectionAlignment(DataRefImpl Sec) 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-19 02:08:55 +08:00
uint32_t Align;
if (is64Bit()) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 Sect = getSection64(Sec);
Align = Sect.align;
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-19 02:08:55 +08:00
} else {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section Sect = getSection(Sec);
Align = Sect.align;
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-19 02:08:55 +08:00
}
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 23:28:58 +08:00
return uint64_t(1) << Align;
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-19 02:08:55 +08:00
}
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 23:28:58 +08:00
bool MachOObjectFile::isSectionText(DataRefImpl Sec) 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-19 02:08:55 +08:00
uint32_t Flags = getSectionFlags(this, Sec);
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 23:28:58 +08:00
return Flags & MachO::S_ATTR_PURE_INSTRUCTIONS;
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-19 02:08:55 +08:00
}
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 23:28:58 +08:00
bool MachOObjectFile::isSectionData(DataRefImpl Sec) const {
Implement MachOObjectFile::isSectionData() and MachOObjectFile::isSectionBSS so that llvm-size will total up all the sections in the Berkeley format. This allows for rough categorizations for Mach-O sections. And allows the total of llvm-size’s Berkeley and System V formats to be the same. llvm-svn: 209158
2014-05-20 04:36:02 +08:00
uint32_t Flags = getSectionFlags(this, Sec);
unsigned SectionType = Flags & MachO::SECTION_TYPE;
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 23:28:58 +08:00
return !(Flags & MachO::S_ATTR_PURE_INSTRUCTIONS) &&
!(SectionType == MachO::S_ZEROFILL ||
SectionType == MachO::S_GB_ZEROFILL);
Object: Add isSection{Data,BSS}. llvm-svn: 140721
2011-09-29 04:57:30 +08:00
}
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 23:28:58 +08:00
bool MachOObjectFile::isSectionBSS(DataRefImpl Sec) const {
Implement MachOObjectFile::isSectionData() and MachOObjectFile::isSectionBSS so that llvm-size will total up all the sections in the Berkeley format. This allows for rough categorizations for Mach-O sections. And allows the total of llvm-size’s Berkeley and System V formats to be the same. llvm-svn: 209158
2014-05-20 04:36:02 +08:00
uint32_t Flags = getSectionFlags(this, Sec);
unsigned SectionType = Flags & MachO::SECTION_TYPE;
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 23:28:58 +08:00
return !(Flags & MachO::S_ATTR_PURE_INSTRUCTIONS) &&
(SectionType == MachO::S_ZEROFILL ||
SectionType == MachO::S_GB_ZEROFILL);
Object: Add isSection{Data,BSS}. llvm-svn: 140721
2011-09-29 04:57:30 +08:00
}
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 23:28:58 +08:00
bool MachOObjectFile::isSectionVirtual(DataRefImpl Sec) const {
Cosmetic changes llvm-svn: 165588
2012-10-10 09:45:52 +08:00
// FIXME: Unimplemented.
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 23:28:58 +08:00
return false;
This patch improves the MCJIT runtime dynamic loader by adding new handling of zero-initialized sections, virtual sections and common symbols and preventing the loading of sections which are not required for execution such as debug information. Patch by Andy Kaylor! llvm-svn: 154610
2012-04-13 04:13:57 +08:00
}
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 23:28:58 +08:00
bool MachOObjectFile::sectionContainsSymbol(DataRefImpl Sec,
DataRefImpl Symb) 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-19 02:08:55 +08:00
SymbolRef::Type ST;
this->getSymbolType(Symb, ST);
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 23:28:58 +08:00
if (ST == SymbolRef::ST_Unknown)
return false;
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-19 02:08:55 +08:00
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 23:28:58 +08:00
uint64_t SectBegin = getSectionAddress(Sec);
uint64_t SectEnd = getSectionSize(Sec);
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-19 02:08:55 +08:00
SectEnd += SectBegin;
uint64_t SymAddr;
getSymbolAddress(Symb, SymAddr);
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 23:28:58 +08:00
return (SymAddr >= SectBegin) && (SymAddr < SectEnd);
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-19 02:08:55 +08: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-28 05:47:05 +08:00
relocation_iterator MachOObjectFile::section_rel_begin(DataRefImpl Sec) const {
Use a pointer as the relocation iterator. Since the relocation iterator walks only the relocations in one section, we can just use a pointer and avoid fetching information about the section at every reference. llvm-svn: 180262
2013-04-25 20:45:46 +08:00
DataRefImpl Ret;
Implement macho relocation iterators with section number + relocation number. This will make it possible to implement getRelocationAddress. llvm-svn: 205587
2014-04-04 07:51:28 +08:00
Ret.d.a = Sec.d.a;
Ret.d.b = 0;
Use a pointer as the relocation iterator. Since the relocation iterator walks only the relocations in one section, we can just use a pointer and avoid fetching information about the section at every reference. llvm-svn: 180262
2013-04-25 20:45:46 +08:00
return relocation_iterator(RelocationRef(Ret, this));
Change relocation API to be per section. This time without breaking GCC. llvm-svn: 141385
2011-10-08 03:25:32 +08:00
}
Template the MachO types over the word size. llvm-svn: 179051
2013-04-09 04:45:01 +08: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-19 02:08:55 +08:00
relocation_iterator
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-28 05:47:05 +08:00
MachOObjectFile::section_rel_end(DataRefImpl Sec) const {
Use a pointer as the relocation iterator. Since the relocation iterator walks only the relocations in one section, we can just use a pointer and avoid fetching information about the section at every reference. llvm-svn: 180262
2013-04-25 20:45:46 +08:00
uint32_t Num;
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-19 02:08:55 +08:00
if (is64Bit()) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 Sect = getSection64(Sec);
Num = Sect.nreloc;
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-19 02:08:55 +08:00
} else {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section Sect = getSection(Sec);
Num = Sect.nreloc;
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-19 02:08:55 +08:00
}
Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08: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-19 02:08:55 +08:00
DataRefImpl Ret;
Implement macho relocation iterators with section number + relocation number. This will make it possible to implement getRelocationAddress. llvm-svn: 205587
2014-04-04 07:51:28 +08:00
Ret.d.a = Sec.d.a;
Ret.d.b = Num;
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-19 02:08:55 +08:00
return relocation_iterator(RelocationRef(Ret, this));
}
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +08:00
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 10:49:50 +08:00
void MachOObjectFile::moveRelocationNext(DataRefImpl &Rel) const {
Implement macho relocation iterators with section number + relocation number. This will make it possible to implement getRelocationAddress. llvm-svn: 205587
2014-04-04 07:51:28 +08:00
++Rel.d.b;
Add support for relocations to ObjectFile. Patch by Danil Malyshev! llvm-svn: 139314
2011-09-09 04:52:17 +08:00
}
More fixes and improvements to MachO relocation pretty-printing, particular for x86 and x86_64 relocations with addends. llvm-svn: 142875
2011-10-25 07:20:07 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getRelocationAddress(DataRefImpl Rel,
uint64_t &Res) const {
Add an assert that this is only used with .o files. I am not sure how to get a relocation in a .dylib, but this function would return the wrong value if passed one. llvm-svn: 205592
2014-04-04 08:31:12 +08:00
uint64_t Offset;
getRelocationOffset(Rel, Offset);
Implement getRelocationAddress for MachO and ET_REL elf files. With that, fix the symbolizer to work with any ELF file. llvm-svn: 205588
2014-04-04 07:54:35 +08:00
DataRefImpl Sec;
Sec.d.a = Rel.d.a;
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 23:28:58 +08:00
uint64_t SecAddress = getSectionAddress(Sec);
Implement getRelocationAddress for MachO and ET_REL elf files. With that, fix the symbolizer to work with any ELF file. llvm-svn: 205588
2014-04-04 07:54:35 +08:00
Res = SecAddress + Offset;
return object_error::success;
[Object] * Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile. * Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable. * Implement this new interface completely for ELF, leave stubs for COFF and MachO. * Add 'llvm-readobj' tool for dumping ObjectFile information. llvm-svn: 151785
2012-03-01 09:36:50 +08: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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getRelocationOffset(DataRefImpl Rel,
uint64_t &Res) const {
Add an assert that this is only used with .o files. I am not sure how to get a relocation in a .dylib, but this function would return the wrong value if passed one. llvm-svn: 205592
2014-04-04 08:31:12 +08:00
assert(getHeader().filetype == MachO::MH_OBJECT &&
"Only implemented for MH_OBJECT");
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::any_relocation_info RE = getRelocation(Rel);
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-19 02:08:55 +08:00
Res = getAnyRelocationAddress(RE);
return object_error::success;
[Object] * Add begin_dynamic_table() / end_dynamic_table() private interface to ELFObjectFile. * Add begin_libraries_needed() / end_libraries_needed() interface to ObjectFile, for grabbing the list of needed libraries for a shared object or dynamic executable. * Implement this new interface completely for ELF, leave stubs for COFF and MachO. * Add 'llvm-readobj' tool for dumping ObjectFile information. llvm-svn: 151785
2012-03-01 09:36:50 +08:00
}
Handle relocations that don't point to symbols. In ELF (as in MachO), not all relocations point to symbols. Represent this properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj ELF's dumper to handle relocatios without symbols. llvm-svn: 183284
2013-06-05 09:33:53 +08:00
symbol_iterator
MachOObjectFile::getRelocationSymbol(DataRefImpl Rel) const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::any_relocation_info RE = getRelocation(Rel);
llvm-readobj: fix MachO relocatoin printing a bit. There were two issues here: 1. At the very least, scattered relocations cannot use the same code to determine the corresponding symbol being referred to. For some reason we pretend there is no symbol, even when one actually exists in the symtab, so to match this behaviour getRelocationSymbol should simply return symbols_end for scattered relocations. 2. Printing "-" when we can't get a symbol (including the scattered case, but not exclusively), isn't that helpful. In both cases there *is* interesting information in that field, so we should print it. As hex will do. Small part of rdar://problem/17553104 llvm-svn: 212332
2014-07-04 18:57:56 +08:00
if (isRelocationScattered(RE))
return symbol_end();
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-19 02:08:55 +08:00
uint32_t SymbolIdx = getPlainRelocationSymbolNum(RE);
bool isExtern = getPlainRelocationExternal(RE);
Handle relocations that don't point to symbols. In ELF (as in MachO), not all relocations point to symbols. Represent this properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj ELF's dumper to handle relocatios without symbols. llvm-svn: 183284
2013-06-05 09:33:53 +08:00
if (!isExtern)
Change the begin and end methods in ObjectFile to match the style guide. llvm-svn: 201108
2014-02-11 04:24:04 +08:00
return symbol_end();
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-19 02:08:55 +08:00
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::symtab_command S = getSymtabLoadCommand();
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
unsigned SymbolTableEntrySize = is64Bit() ?
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
sizeof(MachO::nlist_64) :
sizeof(MachO::nlist);
uint64_t Offset = S.symoff + SymbolIdx * SymbolTableEntrySize;
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-19 02:08:55 +08:00
DataRefImpl Sym;
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
Sym.p = reinterpret_cast<uintptr_t>(getPtr(this, Offset));
Handle relocations that don't point to symbols. In ELF (as in MachO), not all relocations point to symbols. Represent this properly by using a symbol_iterator instead of a SymbolRef. Update llvm-readobj ELF's dumper to handle relocatios without symbols. llvm-svn: 183284
2013-06-05 09:33:53 +08:00
return symbol_iterator(SymbolRef(Sym, this));
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-19 02:08:55 +08:00
}
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-22 05:24:32 +08:00
section_iterator
MachOObjectFile::getRelocationSection(DataRefImpl Rel) const {
return section_iterator(getAnyRelocationSection(getRelocation(Rel)));
}
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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getRelocationType(DataRefImpl Rel,
uint64_t &Res) const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::any_relocation_info RE = getRelocation(Rel);
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-19 02:08:55 +08:00
Res = getAnyRelocationType(RE);
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. llvm-svn: 210835
2014-06-13 05:46:39 +08:00
std::error_code
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-19 02:08:55 +08:00
MachOObjectFile::getRelocationTypeName(DataRefImpl Rel,
SmallVectorImpl<char> &Result) const {
StringRef res;
uint64_t RType;
getRelocationType(Rel, RType);
unsigned Arch = this->getArch();
switch (Arch) {
case Triple::x86: {
static const char *const Table[] = {
"GENERIC_RELOC_VANILLA",
"GENERIC_RELOC_PAIR",
"GENERIC_RELOC_SECTDIFF",
"GENERIC_RELOC_PB_LA_PTR",
"GENERIC_RELOC_LOCAL_SECTDIFF",
"GENERIC_RELOC_TLV" };
Fix a pair of array index checks. Patch by Marius Wachtler. llvm-svn: 196560
2013-12-06 10:33:38 +08:00
if (RType > 5)
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-19 02:08:55 +08:00
res = "Unknown";
else
res = Table[RType];
break;
}
case Triple::x86_64: {
static const char *const Table[] = {
"X86_64_RELOC_UNSIGNED",
"X86_64_RELOC_SIGNED",
"X86_64_RELOC_BRANCH",
"X86_64_RELOC_GOT_LOAD",
"X86_64_RELOC_GOT",
"X86_64_RELOC_SUBTRACTOR",
"X86_64_RELOC_SIGNED_1",
"X86_64_RELOC_SIGNED_2",
"X86_64_RELOC_SIGNED_4",
"X86_64_RELOC_TLV" };
if (RType > 9)
res = "Unknown";
else
res = Table[RType];
break;
}
case Triple::arm: {
static const char *const Table[] = {
"ARM_RELOC_VANILLA",
"ARM_RELOC_PAIR",
"ARM_RELOC_SECTDIFF",
"ARM_RELOC_LOCAL_SECTDIFF",
"ARM_RELOC_PB_LA_PTR",
"ARM_RELOC_BR24",
"ARM_THUMB_RELOC_BR22",
"ARM_THUMB_32BIT_BRANCH",
"ARM_RELOC_HALF",
"ARM_RELOC_HALF_SECTDIFF" };
if (RType > 9)
res = "Unknown";
else
res = Table[RType];
break;
}
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
case Triple::aarch64: {
static const char *const Table[] = {
"ARM64_RELOC_UNSIGNED", "ARM64_RELOC_SUBTRACTOR",
"ARM64_RELOC_BRANCH26", "ARM64_RELOC_PAGE21",
"ARM64_RELOC_PAGEOFF12", "ARM64_RELOC_GOT_LOAD_PAGE21",
"ARM64_RELOC_GOT_LOAD_PAGEOFF12", "ARM64_RELOC_POINTER_TO_GOT",
"ARM64_RELOC_TLVP_LOAD_PAGE21", "ARM64_RELOC_TLVP_LOAD_PAGEOFF12",
"ARM64_RELOC_ADDEND"
};
if (RType >= array_lengthof(Table))
res = "Unknown";
else
res = Table[RType];
break;
}
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-19 02:08:55 +08:00
case Triple::ppc: {
static const char *const Table[] = {
"PPC_RELOC_VANILLA",
"PPC_RELOC_PAIR",
"PPC_RELOC_BR14",
"PPC_RELOC_BR24",
"PPC_RELOC_HI16",
"PPC_RELOC_LO16",
"PPC_RELOC_HA16",
"PPC_RELOC_LO14",
"PPC_RELOC_SECTDIFF",
"PPC_RELOC_PB_LA_PTR",
"PPC_RELOC_HI16_SECTDIFF",
"PPC_RELOC_LO16_SECTDIFF",
"PPC_RELOC_HA16_SECTDIFF",
"PPC_RELOC_JBSR",
"PPC_RELOC_LO14_SECTDIFF",
"PPC_RELOC_LOCAL_SECTDIFF" };
Fix a pair of array index checks. Patch by Marius Wachtler. llvm-svn: 196560
2013-12-06 10:33:38 +08:00
if (RType > 15)
res = "Unknown";
else
res = Table[RType];
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-19 02:08:55 +08:00
break;
}
case Triple::UnknownArch:
res = "Unknown";
break;
}
Result.append(res.begin(), res.end());
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. llvm-svn: 210835
2014-06-13 05:46:39 +08:00
std::error_code MachOObjectFile::getRelocationHidden(DataRefImpl Rel,
bool &Result) 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-19 02:08:55 +08:00
unsigned Arch = getArch();
uint64_t Type;
getRelocationType(Rel, Type);
Result = false;
// On arches that use the generic relocations, GENERIC_RELOC_PAIR
// is always hidden.
initial draft of PPCMachObjectWriter.cpp this records relocation entries in the mach-o object file for PIC code generation. tested on powerpc-darwin8, validated against darwin otool -rvV llvm-svn: 188004
2013-08-09 04:14:40 +08:00
if (Arch == Triple::x86 || Arch == Triple::arm || Arch == Triple::ppc) {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
if (Type == MachO::GENERIC_RELOC_PAIR) Result = true;
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-19 02:08:55 +08:00
} else if (Arch == Triple::x86_64) {
// On x86_64, X86_64_RELOC_UNSIGNED is hidden only when it follows
Typo. llvm-svn: 186886
2013-07-23 06:25:09 +08:00
// an X86_64_RELOC_SUBTRACTOR.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
if (Type == MachO::X86_64_RELOC_UNSIGNED && Rel.d.a > 0) {
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-19 02:08:55 +08:00
DataRefImpl RelPrev = Rel;
RelPrev.d.a--;
uint64_t PrevType;
getRelocationType(RelPrev, PrevType);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
if (PrevType == MachO::X86_64_RELOC_SUBTRACTOR)
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-19 02:08:55 +08:00
Result = true;
}
}
return object_error::success;
}
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-31 03:44:53 +08:00
uint8_t MachOObjectFile::getRelocationLength(DataRefImpl Rel) const {
MachO::any_relocation_info RE = getRelocation(Rel);
return getAnyRelocationLength(RE);
}
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-06 05:21:57 +08:00
//
// guessLibraryShortName() is passed a name of a dynamic library and returns a
// guess on what the short name is. Then name is returned as a substring of the
// StringRef Name passed in. The name of the dynamic library is recognized as
// a framework if it has one of the two following forms:
// Foo.framework/Versions/A/Foo
// Foo.framework/Foo
// Where A and Foo can be any string. And may contain a trailing suffix
// starting with an underbar. If the Name is recognized as a framework then
// isFramework is set to true else it is set to false. If the Name has a
// suffix then Suffix is set to the substring in Name that contains the suffix
// else it is set to a NULL StringRef.
//
// The Name of the dynamic library is recognized as a library name if it has
// one of the two following forms:
// libFoo.A.dylib
// libFoo.dylib
// The library may have a suffix trailing the name Foo of the form:
// libFoo_profile.A.dylib
// libFoo_profile.dylib
//
// The Name of the dynamic library is also recognized as a library name if it
// has the following form:
// Foo.qtx
//
// If the Name of the dynamic library is none of the forms above then a NULL
// StringRef is returned.
//
StringRef MachOObjectFile::guessLibraryShortName(StringRef Name,
bool &isFramework,
StringRef &Suffix) {
StringRef Foo, F, DotFramework, V, Dylib, Lib, Dot, Qtx;
size_t a, b, c, d, Idx;
isFramework = false;
Suffix = StringRef();
// Pull off the last component and make Foo point to it
a = Name.rfind('/');
if (a == Name.npos || a == 0)
goto guess_library;
Foo = Name.slice(a+1, Name.npos);
// Look for a suffix starting with a '_'
Idx = Foo.rfind('_');
if (Idx != Foo.npos && Foo.size() >= 2) {
Suffix = Foo.slice(Idx, Foo.npos);
Foo = Foo.slice(0, Idx);
}
// First look for the form Foo.framework/Foo
b = Name.rfind('/', a);
if (b == Name.npos)
Idx = 0;
else
Idx = b+1;
F = Name.slice(Idx, Idx + Foo.size());
DotFramework = Name.slice(Idx + Foo.size(),
Idx + Foo.size() + sizeof(".framework/")-1);
if (F == Foo && DotFramework == ".framework/") {
isFramework = true;
return Foo;
}
// Next look for the form Foo.framework/Versions/A/Foo
if (b == Name.npos)
goto guess_library;
c = Name.rfind('/', b);
if (c == Name.npos || c == 0)
goto guess_library;
V = Name.slice(c+1, Name.npos);
if (!V.startswith("Versions/"))
goto guess_library;
d = Name.rfind('/', c);
if (d == Name.npos)
Idx = 0;
else
Idx = d+1;
F = Name.slice(Idx, Idx + Foo.size());
DotFramework = Name.slice(Idx + Foo.size(),
Idx + Foo.size() + sizeof(".framework/")-1);
if (F == Foo && DotFramework == ".framework/") {
isFramework = true;
return Foo;
}
guess_library:
// pull off the suffix after the "." and make a point to it
a = Name.rfind('.');
if (a == Name.npos || a == 0)
return StringRef();
Dylib = Name.slice(a, Name.npos);
if (Dylib != ".dylib")
goto guess_qtx;
// First pull off the version letter for the form Foo.A.dylib if any.
if (a >= 3) {
Dot = Name.slice(a-2, a-1);
if (Dot == ".")
a = a - 2;
}
b = Name.rfind('/', a);
if (b == Name.npos)
b = 0;
else
b = b+1;
// ignore any suffix after an underbar like Foo_profile.A.dylib
Idx = Name.find('_', b);
if (Idx != Name.npos && Idx != b) {
Lib = Name.slice(b, Idx);
Suffix = Name.slice(Idx, a);
}
else
Lib = Name.slice(b, a);
// There are incorrect library names of the form:
// libATS.A_profile.dylib so check for these.
if (Lib.size() >= 3) {
Dot = Lib.slice(Lib.size()-2, Lib.size()-1);
if (Dot == ".")
Lib = Lib.slice(0, Lib.size()-2);
}
return Lib;
guess_qtx:
Qtx = Name.slice(a, Name.npos);
if (Qtx != ".qtx")
return StringRef();
b = Name.rfind('/', a);
if (b == Name.npos)
Lib = Name.slice(0, a);
else
Lib = Name.slice(b+1, a);
// There are library names of the form: QT.A.qtx so check for these.
if (Lib.size() >= 3) {
Dot = Lib.slice(Lib.size()-2, Lib.size()-1);
if (Dot == ".")
Lib = Lib.slice(0, Lib.size()-2);
}
return Lib;
}
// getLibraryShortNameByIndex() is used to get the short name of the library
// for an undefined symbol in a linked Mach-O binary that was linked with the
// normal two-level namespace default (that is MH_TWOLEVEL in the header).
// It is passed the index (0 - based) of the library as translated from
// GET_LIBRARY_ORDINAL (1 - based).
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-13 05:46:39 +08:00
std::error_code MachOObjectFile::getLibraryShortNameByIndex(unsigned Index,
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 08:20:14 +08:00
StringRef &Res) 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-06 05:21:57 +08:00
if (Index >= Libraries.size())
return object_error::parse_failed;
// If the cache of LibrariesShortNames is not built up do that first for
// all the Libraries.
if (LibrariesShortNames.size() == 0) {
for (unsigned i = 0; i < Libraries.size(); i++) {
MachO::dylib_command D =
getStruct<MachO::dylib_command>(this, Libraries[i]);
[llvm-objdump] properly use c_str() with format("%s"). Improve getLibraryShortNameByIndex() error handling. llvm-svn: 217930
2014-09-17 08:25:22 +08:00
if (D.dylib.name >= D.cmdsize)
return object_error::parse_failed;
Fix a warning about the use of const being ignored with a cast. llvm-svn: 211383
2014-06-21 02:07:34 +08:00
const char *P = (const char *)(Libraries[i]) + D.dylib.name;
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-06 05:21:57 +08:00
StringRef Name = StringRef(P);
[llvm-objdump] properly use c_str() with format("%s"). Improve getLibraryShortNameByIndex() error handling. llvm-svn: 217930
2014-09-17 08:25:22 +08:00
if (D.dylib.name+Name.size() >= D.cmdsize)
return object_error::parse_failed;
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-06 05:21:57 +08:00
StringRef Suffix;
bool isFramework;
StringRef shortName = guessLibraryShortName(Name, isFramework, Suffix);
[llvm-objdump] properly use c_str() with format("%s"). Improve getLibraryShortNameByIndex() error handling. llvm-svn: 217930
2014-09-17 08:25:22 +08:00
if (shortName.empty())
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-06 05:21:57 +08:00
LibrariesShortNames.push_back(Name);
else
LibrariesShortNames.push_back(shortName);
}
}
Res = LibrariesShortNames[Index];
return object_error::success;
}
Add a SymbolicFile interface between Binary and ObjectFile. This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
2014-02-22 04:10:59 +08:00
basic_symbol_iterator MachOObjectFile::symbol_begin_impl() 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-13 05:39:59 +08:00
return getSymbolByIndex(0);
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-19 02:08:55 +08:00
}
Add a SymbolicFile interface between Binary and ObjectFile. This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
2014-02-22 04:10:59 +08:00
basic_symbol_iterator MachOObjectFile::symbol_end_impl() 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-19 02:08:55 +08:00
DataRefImpl DRI;
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
if (!SymtabLoadCmd)
Add a SymbolicFile interface between Binary and ObjectFile. This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
2014-02-22 04:10:59 +08:00
return basic_symbol_iterator(SymbolRef(DRI, this));
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::symtab_command Symtab = getSymtabLoadCommand();
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
unsigned SymbolTableEntrySize = is64Bit() ?
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
sizeof(MachO::nlist_64) :
sizeof(MachO::nlist);
unsigned Offset = Symtab.symoff +
Symtab.nsyms * SymbolTableEntrySize;
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
DRI.p = reinterpret_cast<uintptr_t>(getPtr(this, Offset));
Add a SymbolicFile interface between Binary and ObjectFile. This interface allows IRObjectFile to be implemented without having dummy methods for all section and segment related methods. Both llvm-ar and llvm-nm are changed to use it. Unfortunately the mangler is still not plugged in since it requires some refactoring to make a Module hold a DataLayout. llvm-svn: 201881
2014-02-22 04:10:59 +08:00
return basic_symbol_iterator(SymbolRef(DRI, this));
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-19 02:08:55 +08: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-13 05:39:59 +08:00
basic_symbol_iterator MachOObjectFile::getSymbolByIndex(unsigned Index) const {
DataRefImpl DRI;
if (!SymtabLoadCmd)
return basic_symbol_iterator(SymbolRef(DRI, this));
MachO::symtab_command Symtab = getSymtabLoadCommand();
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
if (Index >= Symtab.nsyms)
report_fatal_error("Requested symbol index is out of range.");
[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-13 05:39:59 +08:00
unsigned SymbolTableEntrySize =
is64Bit() ? sizeof(MachO::nlist_64) : sizeof(MachO::nlist);
DRI.p = reinterpret_cast<uintptr_t>(getPtr(this, Symtab.symoff));
DRI.p += Index * SymbolTableEntrySize;
return basic_symbol_iterator(SymbolRef(DRI, this));
}
Change the begin and end methods in ObjectFile to match the style guide. llvm-svn: 201108
2014-02-11 04:24:04 +08:00
section_iterator MachOObjectFile::section_begin() 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-19 02:08:55 +08:00
DataRefImpl DRI;
return section_iterator(SectionRef(DRI, this));
}
Change the begin and end methods in ObjectFile to match the style guide. llvm-svn: 201108
2014-02-11 04:24:04 +08:00
section_iterator MachOObjectFile::section_end() 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-19 02:08:55 +08:00
DataRefImpl DRI;
DRI.d.a = Sections.size();
return section_iterator(SectionRef(DRI, this));
}
uint8_t MachOObjectFile::getBytesInAddress() const {
Implement MachOObjectFile::getHeaderSize and MachOObjectFile::getData. These were the last missing forwarding functions. Also consistently use the forwarding functions instead of using MachOObj directly. llvm-svn: 178992
2013-04-08 03:05:30 +08:00
return is64Bit() ? 8 : 4;
Add an ObjectFile implementation for mach-o. Patch by Patrick Walton! llvm-svn: 129974
2011-04-22 11:19:48 +08: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-19 02:08:55 +08:00
StringRef MachOObjectFile::getFileFormatName() const {
unsigned CPUType = getCPUType(this);
if (!is64Bit()) {
switch (CPUType) {
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_I386:
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-19 02:08:55 +08:00
return "Mach-O 32-bit i386";
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_ARM:
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-19 02:08:55 +08:00
return "Mach-O arm";
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_POWERPC:
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-19 02:08:55 +08:00
return "Mach-O 32-bit ppc";
default:
return "Mach-O 32-bit unknown";
}
}
switch (CPUType) {
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_X86_64:
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-19 02:08:55 +08:00
return "Mach-O 64-bit x86-64";
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
case llvm::MachO::CPU_TYPE_ARM64:
return "Mach-O arm64";
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_POWERPC64:
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-19 02:08:55 +08:00
return "Mach-O 64-bit ppc64";
default:
return "Mach-O 64-bit unknown";
}
}
Basic support for parsing Mach-O universal binaries in LLVMObject library llvm-svn: 184191
2013-06-18 23:03:28 +08:00
Triple::ArchType MachOObjectFile::getArch(uint32_t CPUType) {
switch (CPUType) {
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_I386:
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-19 02:08:55 +08:00
return Triple::x86;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_X86_64:
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-19 02:08:55 +08:00
return Triple::x86_64;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_ARM:
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-19 02:08:55 +08:00
return Triple::arm;
ARM64: initial backend import This adds a second implementation of the AArch64 architecture to LLVM, accessible in parallel via the "arm64" triple. The plan over the coming weeks & months is to merge the two into a single backend, during which time thorough code review should naturally occur. Everything will be easier with the target in-tree though, hence this commit. llvm-svn: 205090
2014-03-29 18:18:08 +08:00
case llvm::MachO::CPU_TYPE_ARM64:
AArch64: remove arm64 triple enumerator. Having both Triple::arm64 and Triple::aarch64 is extremely confusing, and invites bugs where only one is checked. In reality, the only legitimate difference between the two (arm64 usually means iOS) is also present in the OS part of the triple and that's what should be checked. We still parse the "arm64" triple, just canonicalise it to Triple::aarch64, so there aren't any LLVM-side test changes. llvm-svn: 213743
2014-07-23 20:32:47 +08:00
return Triple::aarch64;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_POWERPC:
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-19 02:08:55 +08:00
return Triple::ppc;
Support/MachO: Add a bunch of defines. Right now we have two headers for the Mach-O format. I'd like to get rid of one. Since the other object formats are all in Support, I chose to keep the Mach-O header in Support, and discard the other one. llvm-svn: 189314
2013-08-27 13:00:13 +08:00
case llvm::MachO::CPU_TYPE_POWERPC64:
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-19 02:08:55 +08:00
return Triple::ppc64;
default:
return Triple::UnknownArch;
}
}
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
Triple MachOObjectFile::getArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault) {
if (McpuDefault)
*McpuDefault = nullptr;
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-07-01 02:45:23 +08:00
switch (CPUType) {
case MachO::CPU_TYPE_I386:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_I386_ALL:
return Triple("i386-apple-darwin");
default:
return Triple();
}
case MachO::CPU_TYPE_X86_64:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_X86_64_ALL:
return Triple("x86_64-apple-darwin");
case MachO::CPU_SUBTYPE_X86_64_H:
return Triple("x86_64h-apple-darwin");
default:
return Triple();
}
case MachO::CPU_TYPE_ARM:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_ARM_V4T:
return Triple("armv4t-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V5TEJ:
return Triple("armv5e-apple-darwin");
Add two missing ARM cpusubtypes to the switch statement in MachOObjectFile::getArch(uint32_t CPUType, uint32_t CPUSubType) . Upcoming changes will cause existing test cases to use this but I wanted to check in this obvious change separately. llvm-svn: 215150
2014-08-08 05:30:25 +08:00
case MachO::CPU_SUBTYPE_ARM_XSCALE:
return Triple("xscale-apple-darwin");
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-07-01 02:45:23 +08:00
case MachO::CPU_SUBTYPE_ARM_V6:
return Triple("armv6-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V6M:
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
if (McpuDefault)
*McpuDefault = "cortex-m0";
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-07-01 02:45:23 +08:00
return Triple("armv6m-apple-darwin");
Add two missing ARM cpusubtypes to the switch statement in MachOObjectFile::getArch(uint32_t CPUType, uint32_t CPUSubType) . Upcoming changes will cause existing test cases to use this but I wanted to check in this obvious change separately. llvm-svn: 215150
2014-08-08 05:30:25 +08:00
case MachO::CPU_SUBTYPE_ARM_V7:
return Triple("armv7-apple-darwin");
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-07-01 02:45:23 +08:00
case MachO::CPU_SUBTYPE_ARM_V7EM:
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
if (McpuDefault)
*McpuDefault = "cortex-m4";
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-07-01 02:45:23 +08:00
return Triple("armv7em-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7K:
return Triple("armv7k-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7M:
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
if (McpuDefault)
*McpuDefault = "cortex-m3";
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-07-01 02:45:23 +08:00
return Triple("armv7m-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7S:
return Triple("armv7s-apple-darwin");
default:
return Triple();
}
case MachO::CPU_TYPE_ARM64:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_ARM64_ALL:
return Triple("arm64-apple-darwin");
default:
return Triple();
}
case MachO::CPU_TYPE_POWERPC:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_POWERPC_ALL:
return Triple("ppc-apple-darwin");
default:
return Triple();
}
case MachO::CPU_TYPE_POWERPC64:
Speculatively fix some code handling Power64 MachO files MSVC was warning on a switch containing only default labels. In this instance, it looks like it uncovered a real bug. :) llvm-svn: 212062
2014-07-01 04:12:59 +08:00
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
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-07-01 02:45:23 +08:00
case MachO::CPU_SUBTYPE_POWERPC_ALL:
return Triple("ppc64-apple-darwin");
default:
return Triple();
}
default:
return Triple();
}
}
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
Triple MachOObjectFile::getThumbArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault) {
if (McpuDefault)
*McpuDefault = nullptr;
switch (CPUType) {
case MachO::CPU_TYPE_ARM:
switch (CPUSubType & ~MachO::CPU_SUBTYPE_MASK) {
case MachO::CPU_SUBTYPE_ARM_V4T:
return Triple("thumbv4t-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V5TEJ:
return Triple("thumbv5e-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_XSCALE:
return Triple("xscale-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V6:
return Triple("thumbv6-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V6M:
if (McpuDefault)
*McpuDefault = "cortex-m0";
return Triple("thumbv6m-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7:
return Triple("thumbv7-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7EM:
if (McpuDefault)
*McpuDefault = "cortex-m4";
return Triple("thumbv7em-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7K:
return Triple("thumbv7k-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7M:
if (McpuDefault)
*McpuDefault = "cortex-m3";
return Triple("thumbv7m-apple-darwin");
case MachO::CPU_SUBTYPE_ARM_V7S:
return Triple("thumbv7s-apple-darwin");
default:
return Triple();
}
default:
return Triple();
}
}
Triple MachOObjectFile::getArch(uint32_t CPUType, uint32_t CPUSubType,
const char **McpuDefault,
Triple *ThumbTriple) {
Triple T = MachOObjectFile::getArch(CPUType, CPUSubType, McpuDefault);
*ThumbTriple = MachOObjectFile::getThumbArch(CPUType, CPUSubType,
McpuDefault);
return T;
}
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-07-01 02:45:23 +08:00
Triple MachOObjectFile::getHostArch() {
return Triple(sys::getDefaultTargetTriple());
}
Use a simpler predicate. NFC. llvm-svn: 215218
2014-08-09 00:30:17 +08:00
bool MachOObjectFile::isValidArch(StringRef ArchFlag) {
return StringSwitch<bool>(ArchFlag)
.Case("i386", true)
.Case("x86_64", true)
.Case("x86_64h", true)
.Case("armv4t", true)
.Case("arm", true)
.Case("armv5e", true)
.Case("armv6", true)
.Case("armv6m", true)
.Case("armv7em", true)
.Case("armv7k", true)
.Case("armv7m", true)
.Case("armv7s", true)
.Case("arm64", true)
.Case("ppc", true)
.Case("ppc64", true)
.Default(false);
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-07-01 02:45:23 +08:00
}
Basic support for parsing Mach-O universal binaries in LLVMObject library llvm-svn: 184191
2013-06-18 23:03:28 +08:00
unsigned MachOObjectFile::getArch() const {
return getArch(getCPUType(this));
}
Make llvm-objdump handle both arm and thumb disassembly from the same Mach-O file with -macho, the Mach-O specific object file parser option. After some discussion I chose to do this implementation contained in the logic of llvm-objdump’s MachODump.cpp using a second disassembler for thumb when needed and with updates mostly contained in the MachOObjectFile class. llvm-svn: 215931
2014-08-19 04:21:02 +08:00
Triple MachOObjectFile::getArch(const char **McpuDefault,
Triple *ThumbTriple) const {
Triple T;
if (is64Bit()) {
MachO::mach_header_64 H_64;
H_64 = getHeader64();
T = MachOObjectFile::getArch(H_64.cputype, H_64.cpusubtype, McpuDefault);
*ThumbTriple = MachOObjectFile::getThumbArch(H_64.cputype, H_64.cpusubtype,
McpuDefault);
} else {
MachO::mach_header H;
H = getHeader();
T = MachOObjectFile::getArch(H.cputype, H.cpusubtype, McpuDefault);
*ThumbTriple = MachOObjectFile::getThumbArch(H.cputype, H.cpusubtype,
McpuDefault);
}
return T;
}
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-28 05:47:05 +08:00
relocation_iterator MachOObjectFile::section_rel_begin(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-27 04:07:33 +08:00
DataRefImpl DRI;
DRI.d.a = Index;
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-28 05:47:05 +08:00
return section_rel_begin(DRI);
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-27 04:07:33 +08: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-28 05:47:05 +08:00
relocation_iterator MachOObjectFile::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-27 04:07:33 +08:00
DataRefImpl DRI;
DRI.d.a = Index;
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-28 05:47:05 +08:00
return section_rel_end(DRI);
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-27 04:07:33 +08: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-07 01:20:50 +08:00
dice_iterator MachOObjectFile::begin_dices() const {
DataRefImpl DRI;
if (!DataInCodeLoadCmd)
return dice_iterator(DiceRef(DRI, this));
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::linkedit_data_command DicLC = getDataInCodeLoadCommand();
DRI.p = reinterpret_cast<uintptr_t>(getPtr(this, DicLC.dataoff));
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-07 01:20:50 +08:00
return dice_iterator(DiceRef(DRI, this));
}
dice_iterator MachOObjectFile::end_dices() const {
DataRefImpl DRI;
if (!DataInCodeLoadCmd)
return dice_iterator(DiceRef(DRI, this));
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::linkedit_data_command DicLC = getDataInCodeLoadCommand();
unsigned Offset = DicLC.dataoff + DicLC.datasize;
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-07 01:20:50 +08:00
DRI.p = reinterpret_cast<uintptr_t>(getPtr(this, Offset));
return dice_iterator(DiceRef(DRI, this));
}
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 08:20:14 +08:00
ExportEntry::ExportEntry(ArrayRef<uint8_t> T)
: Trie(T), Malformed(false), Done(false) { }
void ExportEntry::moveToFirst() {
pushNode(0);
pushDownUntilBottom();
}
void ExportEntry::moveToEnd() {
Stack.clear();
Done = true;
}
bool ExportEntry::operator==(const ExportEntry &Other) const {
// Common case, one at end, other iterating from begin.
if (Done || Other.Done)
return (Done == Other.Done);
// Not equal if different stack sizes.
if (Stack.size() != Other.Stack.size())
return false;
// Not equal if different cumulative strings.
Remove more superfluous .str() and replace std::string concatenation with Twine. Following r233392, http://llvm.org/viewvc/llvm-project?rev=233392&view=rev. llvm-svn: 233555
2015-03-30 23:42:36 +08:00
if (!CumulativeString.equals(Other.CumulativeString))
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 08:20:14 +08:00
return false;
// Equal if all nodes in both stacks match.
for (unsigned i=0; i < Stack.size(); ++i) {
if (Stack[i].Start != Other.Stack[i].Start)
return false;
}
return true;
}
Code review tweaks llvm-svn: 216931
2014-09-03 02:50:24 +08:00
uint64_t ExportEntry::readULEB128(const uint8_t *&Ptr) {
unsigned Count;
uint64_t Result = decodeULEB128(Ptr, &Count);
Ptr += Count;
if (Ptr > Trie.end()) {
Ptr = Trie.end();
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 08:20:14 +08:00
Malformed = true;
}
Code review tweaks llvm-svn: 216931
2014-09-03 02:50:24 +08:00
return Result;
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 08:20:14 +08:00
}
StringRef ExportEntry::name() const {
Remove more superfluous .str() and replace std::string concatenation with Twine. Following r233392, http://llvm.org/viewvc/llvm-project?rev=233392&view=rev. llvm-svn: 233555
2015-03-30 23:42:36 +08:00
return CumulativeString;
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 08:20:14 +08:00
}
uint64_t ExportEntry::flags() const {
return Stack.back().Flags;
}
uint64_t ExportEntry::address() const {
return Stack.back().Address;
}
uint64_t ExportEntry::other() const {
return Stack.back().Other;
}
StringRef ExportEntry::otherName() const {
const char* ImportName = Stack.back().ImportName;
if (ImportName)
return StringRef(ImportName);
return StringRef();
}
uint32_t ExportEntry::nodeOffset() const {
return Stack.back().Start - Trie.begin();
}
ExportEntry::NodeState::NodeState(const uint8_t *Ptr)
: Start(Ptr), Current(Ptr), Flags(0), Address(0), Other(0),
ImportName(nullptr), ChildCount(0), NextChildIndex(0),
ParentStringLength(0), IsExportNode(false) {
}
void ExportEntry::pushNode(uint64_t offset) {
const uint8_t *Ptr = Trie.begin() + offset;
NodeState State(Ptr);
uint64_t ExportInfoSize = readULEB128(State.Current);
State.IsExportNode = (ExportInfoSize != 0);
const uint8_t* Children = State.Current + ExportInfoSize;
if (State.IsExportNode) {
State.Flags = readULEB128(State.Current);
if (State.Flags & MachO::EXPORT_SYMBOL_FLAGS_REEXPORT) {
State.Address = 0;
State.Other = readULEB128(State.Current); // dylib ordinal
State.ImportName = reinterpret_cast<const char*>(State.Current);
} else {
State.Address = readULEB128(State.Current);
Fix typo and formatting llvm-svn: 216809
2014-08-30 09:57:34 +08:00
if (State.Flags & MachO::EXPORT_SYMBOL_FLAGS_STUB_AND_RESOLVER)
State.Other = readULEB128(State.Current);
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 08:20:14 +08:00
}
}
State.ChildCount = *Children;
State.Current = Children + 1;
State.NextChildIndex = 0;
State.ParentStringLength = CumulativeString.size();
Stack.push_back(State);
}
void ExportEntry::pushDownUntilBottom() {
while (Stack.back().NextChildIndex < Stack.back().ChildCount) {
NodeState &Top = Stack.back();
CumulativeString.resize(Top.ParentStringLength);
for (;*Top.Current != 0; Top.Current++) {
Code review tweaks llvm-svn: 216931
2014-09-03 02:50:24 +08:00
char C = *Top.Current;
CumulativeString.push_back(C);
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 08:20:14 +08:00
}
Top.Current += 1;
uint64_t childNodeIndex = readULEB128(Top.Current);
Top.NextChildIndex += 1;
pushNode(childNodeIndex);
}
if (!Stack.back().IsExportNode) {
Malformed = true;
moveToEnd();
}
}
// We have a trie data structure and need a way to walk it that is compatible
// with the C++ iterator model. The solution is a non-recursive depth first
// traversal where the iterator contains a stack of parent nodes along with a
// string that is the accumulation of all edge strings along the parent chain
// to this point.
//
Fix unicode chars into ascii in comment lines. llvm-svn: 220668
2014-10-27 16:08:18 +08:00
// There is one "export" node for each exported symbol. But because some
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 08:20:14 +08:00
// symbols may be a prefix of another symbol (e.g. _dup and _dup2), an export
// node may have child nodes too.
//
// The algorithm for moveNext() is to keep moving down the leftmost unvisited
// child until hitting a node with no children (which is an export node or
// else the trie is malformed). On the way down, each node is pushed on the
// stack ivar. If there is no more ways down, it pops up one and tries to go
// down a sibling path until a childless node is reached.
void ExportEntry::moveNext() {
if (Stack.empty() || !Stack.back().IsExportNode) {
Malformed = true;
moveToEnd();
return;
}
Stack.pop_back();
while (!Stack.empty()) {
NodeState &Top = Stack.back();
if (Top.NextChildIndex < Top.ChildCount) {
pushDownUntilBottom();
// Now at the next export node.
return;
} else {
if (Top.IsExportNode) {
// This node has no children but is itself an export node.
CumulativeString.resize(Top.ParentStringLength);
return;
}
Stack.pop_back();
}
}
Done = true;
}
iterator_range<export_iterator>
MachOObjectFile::exports(ArrayRef<uint8_t> Trie) {
ExportEntry Start(Trie);
[Object] Don't crash on empty export lists. Summary: This fixes the exports iterator if the export list is empty. Reviewers: Bigcheese, kledzik Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6732 llvm-svn: 224563
2014-12-19 10:31:01 +08:00
if (Trie.size() == 0)
Start.moveToEnd();
else
Start.moveToFirst();
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 08:20:14 +08:00
ExportEntry Finish(Trie);
Finish.moveToEnd();
return iterator_range<export_iterator>(export_iterator(Start),
export_iterator(Finish));
}
iterator_range<export_iterator> MachOObjectFile::exports() const {
return exports(getDyldInfoExportsTrie());
}
[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-13 05:34:15 +08:00
MachORebaseEntry::MachORebaseEntry(ArrayRef<uint8_t> Bytes, bool is64Bit)
: Opcodes(Bytes), Ptr(Bytes.begin()), SegmentOffset(0), SegmentIndex(0),
RemainingLoopCount(0), AdvanceAmount(0), RebaseType(0),
PointerSize(is64Bit ? 8 : 4), Malformed(false), Done(false) {}
void MachORebaseEntry::moveToFirst() {
Ptr = Opcodes.begin();
moveNext();
}
void MachORebaseEntry::moveToEnd() {
Ptr = Opcodes.end();
RemainingLoopCount = 0;
Done = true;
}
void MachORebaseEntry::moveNext() {
// If in the middle of some loop, move to next rebasing in loop.
SegmentOffset += AdvanceAmount;
if (RemainingLoopCount) {
--RemainingLoopCount;
return;
}
if (Ptr == Opcodes.end()) {
Done = true;
return;
}
bool More = true;
while (More && !Malformed) {
// Parse next opcode and set up next loop.
uint8_t Byte = *Ptr++;
uint8_t ImmValue = Byte & MachO::REBASE_IMMEDIATE_MASK;
uint8_t Opcode = Byte & MachO::REBASE_OPCODE_MASK;
switch (Opcode) {
case MachO::REBASE_OPCODE_DONE:
More = false;
Done = true;
moveToEnd();
DEBUG_WITH_TYPE("mach-o-rebase", llvm::dbgs() << "REBASE_OPCODE_DONE\n");
break;
case MachO::REBASE_OPCODE_SET_TYPE_IMM:
RebaseType = ImmValue;
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_SET_TYPE_IMM: "
<< "RebaseType=" << (int) RebaseType << "\n");
break;
case MachO::REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB:
SegmentIndex = ImmValue;
SegmentOffset = readULEB128();
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB: "
<< "SegmentIndex=" << SegmentIndex << ", "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< "\n");
break;
case MachO::REBASE_OPCODE_ADD_ADDR_ULEB:
SegmentOffset += readULEB128();
DEBUG_WITH_TYPE("mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_ADD_ADDR_ULEB: "
<< format("SegmentOffset=0x%06X",
SegmentOffset) << "\n");
break;
case MachO::REBASE_OPCODE_ADD_ADDR_IMM_SCALED:
SegmentOffset += ImmValue * PointerSize;
DEBUG_WITH_TYPE("mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_ADD_ADDR_IMM_SCALED: "
<< format("SegmentOffset=0x%06X",
SegmentOffset) << "\n");
break;
case MachO::REBASE_OPCODE_DO_REBASE_IMM_TIMES:
AdvanceAmount = PointerSize;
RemainingLoopCount = ImmValue - 1;
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_DO_REBASE_IMM_TIMES: "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
case MachO::REBASE_OPCODE_DO_REBASE_ULEB_TIMES:
AdvanceAmount = PointerSize;
RemainingLoopCount = readULEB128() - 1;
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_DO_REBASE_ULEB_TIMES: "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
case MachO::REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB:
AdvanceAmount = readULEB128() + PointerSize;
RemainingLoopCount = 0;
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_DO_REBASE_ADD_ADDR_ULEB: "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
case MachO::REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB:
RemainingLoopCount = readULEB128() - 1;
AdvanceAmount = readULEB128() + PointerSize;
DEBUG_WITH_TYPE(
"mach-o-rebase",
llvm::dbgs() << "REBASE_OPCODE_DO_REBASE_ULEB_TIMES_SKIPPING_ULEB: "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
default:
Malformed = true;
}
}
}
uint64_t MachORebaseEntry::readULEB128() {
unsigned Count;
uint64_t Result = decodeULEB128(Ptr, &Count);
Ptr += Count;
if (Ptr > Opcodes.end()) {
Ptr = Opcodes.end();
Malformed = true;
}
return Result;
}
uint32_t MachORebaseEntry::segmentIndex() const { return SegmentIndex; }
uint64_t MachORebaseEntry::segmentOffset() const { return SegmentOffset; }
StringRef MachORebaseEntry::typeName() const {
switch (RebaseType) {
case MachO::REBASE_TYPE_POINTER:
return "pointer";
case MachO::REBASE_TYPE_TEXT_ABSOLUTE32:
return "text abs32";
case MachO::REBASE_TYPE_TEXT_PCREL32:
return "text rel32";
}
return "unknown";
}
bool MachORebaseEntry::operator==(const MachORebaseEntry &Other) const {
assert(Opcodes == Other.Opcodes && "compare iterators of different files");
return (Ptr == Other.Ptr) &&
(RemainingLoopCount == Other.RemainingLoopCount) &&
(Done == Other.Done);
}
iterator_range<rebase_iterator>
MachOObjectFile::rebaseTable(ArrayRef<uint8_t> Opcodes, bool is64) {
MachORebaseEntry Start(Opcodes, is64);
Start.moveToFirst();
MachORebaseEntry Finish(Opcodes, is64);
Finish.moveToEnd();
return iterator_range<rebase_iterator>(rebase_iterator(Start),
rebase_iterator(Finish));
}
iterator_range<rebase_iterator> MachOObjectFile::rebaseTable() const {
return rebaseTable(getDyldInfoRebaseOpcodes(), is64Bit());
}
[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 09:41:51 +08:00
MachOBindEntry::MachOBindEntry(ArrayRef<uint8_t> Bytes, bool is64Bit,
Kind BK)
: Opcodes(Bytes), Ptr(Bytes.begin()), SegmentOffset(0), SegmentIndex(0),
Ordinal(0), Flags(0), Addend(0), RemainingLoopCount(0), AdvanceAmount(0),
BindType(0), PointerSize(is64Bit ? 8 : 4),
TableKind(BK), Malformed(false), Done(false) {}
void MachOBindEntry::moveToFirst() {
Ptr = Opcodes.begin();
moveNext();
}
void MachOBindEntry::moveToEnd() {
Ptr = Opcodes.end();
RemainingLoopCount = 0;
Done = true;
}
void MachOBindEntry::moveNext() {
// If in the middle of some loop, move to next binding in loop.
SegmentOffset += AdvanceAmount;
if (RemainingLoopCount) {
--RemainingLoopCount;
return;
}
if (Ptr == Opcodes.end()) {
Done = true;
return;
}
bool More = true;
while (More && !Malformed) {
// Parse next opcode and set up next loop.
uint8_t Byte = *Ptr++;
uint8_t ImmValue = Byte & MachO::BIND_IMMEDIATE_MASK;
uint8_t Opcode = Byte & MachO::BIND_OPCODE_MASK;
int8_t SignExtended;
const uint8_t *SymStart;
switch (Opcode) {
case MachO::BIND_OPCODE_DONE:
if (TableKind == Kind::Lazy) {
// Lazying bindings have a DONE opcode between entries. Need to ignore
// it to advance to next entry. But need not if this is last entry.
bool NotLastEntry = false;
for (const uint8_t *P = Ptr; P < Opcodes.end(); ++P) {
if (*P) {
NotLastEntry = true;
}
}
if (NotLastEntry)
break;
}
More = false;
Done = true;
moveToEnd();
DEBUG_WITH_TYPE("mach-o-bind", llvm::dbgs() << "BIND_OPCODE_DONE\n");
break;
case MachO::BIND_OPCODE_SET_DYLIB_ORDINAL_IMM:
Ordinal = ImmValue;
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_DYLIB_ORDINAL_IMM: "
<< "Ordinal=" << Ordinal << "\n");
break;
case MachO::BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB:
Ordinal = readULEB128();
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB: "
<< "Ordinal=" << Ordinal << "\n");
break;
case MachO::BIND_OPCODE_SET_DYLIB_SPECIAL_IMM:
if (ImmValue) {
SignExtended = MachO::BIND_OPCODE_MASK | ImmValue;
Ordinal = SignExtended;
} else
Ordinal = 0;
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_DYLIB_SPECIAL_IMM: "
<< "Ordinal=" << Ordinal << "\n");
break;
case MachO::BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM:
Flags = ImmValue;
SymStart = Ptr;
while (*Ptr) {
++Ptr;
}
SymbolName = StringRef(reinterpret_cast<const char*>(SymStart),
Ptr-SymStart);
[Object] keep trailing '\0' out of StringRef when parsing mach-o bindings llvm-svn: 217935
2014-09-17 09:51:43 +08:00
++Ptr;
[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 09:41:51 +08:00
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_SYMBOL_TRAILING_FLAGS_IMM: "
<< "SymbolName=" << SymbolName << "\n");
if (TableKind == Kind::Weak) {
if (ImmValue & MachO::BIND_SYMBOL_FLAGS_NON_WEAK_DEFINITION)
return;
}
break;
case MachO::BIND_OPCODE_SET_TYPE_IMM:
BindType = ImmValue;
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_TYPE_IMM: "
<< "BindType=" << (int)BindType << "\n");
break;
case MachO::BIND_OPCODE_SET_ADDEND_SLEB:
Addend = readSLEB128();
if (TableKind == Kind::Lazy)
Malformed = true;
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_ADDEND_SLEB: "
<< "Addend=" << Addend << "\n");
break;
case MachO::BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB:
SegmentIndex = ImmValue;
SegmentOffset = readULEB128();
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_SET_SEGMENT_AND_OFFSET_ULEB: "
<< "SegmentIndex=" << SegmentIndex << ", "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< "\n");
break;
case MachO::BIND_OPCODE_ADD_ADDR_ULEB:
SegmentOffset += readULEB128();
DEBUG_WITH_TYPE("mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_ADD_ADDR_ULEB: "
<< format("SegmentOffset=0x%06X",
SegmentOffset) << "\n");
break;
case MachO::BIND_OPCODE_DO_BIND:
AdvanceAmount = PointerSize;
RemainingLoopCount = 0;
DEBUG_WITH_TYPE("mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_DO_BIND: "
<< format("SegmentOffset=0x%06X",
SegmentOffset) << "\n");
return;
case MachO::BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB:
[llvm-objdump] Fix mach-o binding decompression error llvm-svn: 220119
2014-10-18 09:21:02 +08:00
AdvanceAmount = readULEB128() + PointerSize;
[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 09:41:51 +08:00
RemainingLoopCount = 0;
if (TableKind == Kind::Lazy)
Malformed = true;
DEBUG_WITH_TYPE(
"mach-o-bind",
[llvm-objdump] Fix mach-o binding decompression error llvm-svn: 220119
2014-10-18 09:21:02 +08:00
llvm::dbgs() << "BIND_OPCODE_DO_BIND_ADD_ADDR_ULEB: "
[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 09:41:51 +08:00
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
case MachO::BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED:
[llvm-objdump] Fix mach-o binding decompression error llvm-svn: 220119
2014-10-18 09:21:02 +08:00
AdvanceAmount = ImmValue * PointerSize + PointerSize;
[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 09:41:51 +08:00
RemainingLoopCount = 0;
if (TableKind == Kind::Lazy)
Malformed = true;
DEBUG_WITH_TYPE("mach-o-bind",
llvm::dbgs()
<< "BIND_OPCODE_DO_BIND_ADD_ADDR_IMM_SCALED: "
<< format("SegmentOffset=0x%06X",
SegmentOffset) << "\n");
return;
case MachO::BIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB:
RemainingLoopCount = readULEB128() - 1;
AdvanceAmount = readULEB128() + PointerSize;
if (TableKind == Kind::Lazy)
Malformed = true;
DEBUG_WITH_TYPE(
"mach-o-bind",
llvm::dbgs() << "BIND_OPCODE_DO_BIND_ULEB_TIMES_SKIPPING_ULEB: "
<< format("SegmentOffset=0x%06X", SegmentOffset)
<< ", AdvanceAmount=" << AdvanceAmount
<< ", RemainingLoopCount=" << RemainingLoopCount
<< "\n");
return;
default:
Malformed = true;
}
}
}
uint64_t MachOBindEntry::readULEB128() {
unsigned Count;
uint64_t Result = decodeULEB128(Ptr, &Count);
Ptr += Count;
if (Ptr > Opcodes.end()) {
Ptr = Opcodes.end();
Malformed = true;
}
return Result;
}
int64_t MachOBindEntry::readSLEB128() {
unsigned Count;
int64_t Result = decodeSLEB128(Ptr, &Count);
Ptr += Count;
if (Ptr > Opcodes.end()) {
Ptr = Opcodes.end();
Malformed = true;
}
return Result;
}
uint32_t MachOBindEntry::segmentIndex() const { return SegmentIndex; }
uint64_t MachOBindEntry::segmentOffset() const { return SegmentOffset; }
StringRef MachOBindEntry::typeName() const {
switch (BindType) {
case MachO::BIND_TYPE_POINTER:
return "pointer";
case MachO::BIND_TYPE_TEXT_ABSOLUTE32:
return "text abs32";
case MachO::BIND_TYPE_TEXT_PCREL32:
return "text rel32";
}
return "unknown";
}
StringRef MachOBindEntry::symbolName() const { return SymbolName; }
int64_t MachOBindEntry::addend() const { return Addend; }
uint32_t MachOBindEntry::flags() const { return Flags; }
int MachOBindEntry::ordinal() const { return Ordinal; }
bool MachOBindEntry::operator==(const MachOBindEntry &Other) const {
assert(Opcodes == Other.Opcodes && "compare iterators of different files");
return (Ptr == Other.Ptr) &&
(RemainingLoopCount == Other.RemainingLoopCount) &&
(Done == Other.Done);
}
iterator_range<bind_iterator>
MachOObjectFile::bindTable(ArrayRef<uint8_t> Opcodes, bool is64,
MachOBindEntry::Kind BKind) {
MachOBindEntry Start(Opcodes, is64, BKind);
Start.moveToFirst();
MachOBindEntry Finish(Opcodes, is64, BKind);
Finish.moveToEnd();
return iterator_range<bind_iterator>(bind_iterator(Start),
bind_iterator(Finish));
}
iterator_range<bind_iterator> MachOObjectFile::bindTable() const {
return bindTable(getDyldInfoBindOpcodes(), is64Bit(),
MachOBindEntry::Kind::Regular);
}
iterator_range<bind_iterator> MachOObjectFile::lazyBindTable() const {
return bindTable(getDyldInfoLazyBindOpcodes(), is64Bit(),
MachOBindEntry::Kind::Lazy);
}
iterator_range<bind_iterator> MachOObjectFile::weakBindTable() const {
return bindTable(getDyldInfoWeakBindOpcodes(), is64Bit(),
MachOBindEntry::Kind::Weak);
}
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-19 02:08:55 +08:00
StringRef
MachOObjectFile::getSectionFinalSegmentName(DataRefImpl Sec) const {
ArrayRef<char> Raw = getSectionRawFinalSegmentName(Sec);
return parseSegmentOrSectionName(Raw.data());
}
ArrayRef<char>
MachOObjectFile::getSectionRawName(DataRefImpl Sec) const {
Detect invalid section indexes when we first read them. We still detect the same errors, but now we do it earlier. llvm-svn: 238024
2015-05-22 22:59:27 +08:00
assert(Sec.d.a < Sections.size() && "Should have detected this earlier");
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const section_base *Base =
reinterpret_cast<const section_base *>(Sections[Sec.d.a]);
Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or just letting them be implicitly created. llvm-svn: 216525
2014-08-27 13:25:25 +08:00
return makeArrayRef(Base->sectname);
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-19 02:08:55 +08:00
}
ArrayRef<char>
MachOObjectFile::getSectionRawFinalSegmentName(DataRefImpl Sec) const {
Detect invalid section indexes when we first read them. We still detect the same errors, but now we do it earlier. llvm-svn: 238024
2015-05-22 22:59:27 +08:00
assert(Sec.d.a < Sections.size() && "Should have detected this earlier");
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const section_base *Base =
reinterpret_cast<const section_base *>(Sections[Sec.d.a]);
Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or just letting them be implicitly created. llvm-svn: 216525
2014-08-27 13:25:25 +08:00
return makeArrayRef(Base->segname);
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-19 02:08:55 +08:00
}
bool
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachOObjectFile::isRelocationScattered(const MachO::any_relocation_info &RE)
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-19 02:08:55 +08:00
const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
if (getCPUType(this) == MachO::CPU_TYPE_X86_64)
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-19 02:08:55 +08:00
return false;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getPlainRelocationAddress(RE) & MachO::R_SCATTERED;
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-19 02:08:55 +08:00
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
unsigned MachOObjectFile::getPlainRelocationSymbolNum(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
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-19 02:08:55 +08:00
if (isLittleEndian())
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return RE.r_word1 & 0xffffff;
return RE.r_word1 >> 8;
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-19 02:08:55 +08:00
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
bool MachOObjectFile::getPlainRelocationExternal(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
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-19 02:08:55 +08:00
if (isLittleEndian())
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return (RE.r_word1 >> 27) & 1;
return (RE.r_word1 >> 4) & 1;
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-19 02:08:55 +08:00
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
bool MachOObjectFile::getScatteredRelocationScattered(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) const {
return RE.r_word0 >> 31;
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-19 02:08:55 +08:00
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
uint32_t MachOObjectFile::getScatteredRelocationValue(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) const {
return RE.r_word1;
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-19 02:08:55 +08:00
}
Add the code and test cases for 32-bit Intel to llvm-objdump’s Mach-O symbolizer. llvm-svn: 221211
2014-11-04 08:43:16 +08:00
uint32_t MachOObjectFile::getScatteredRelocationType(
const MachO::any_relocation_info &RE) const {
return (RE.r_word0 >> 24) & 0xf;
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
unsigned MachOObjectFile::getAnyRelocationAddress(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
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-19 02:08:55 +08:00
if (isRelocationScattered(RE))
return getScatteredRelocationAddress(RE);
return getPlainRelocationAddress(RE);
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
unsigned MachOObjectFile::getAnyRelocationPCRel(
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-19 02:08:55 +08:00
if (isRelocationScattered(RE))
return getScatteredRelocationPCRel(this, RE);
return getPlainRelocationPCRel(this, RE);
}
80-column tidying. Formatting choices by clang-format. llvm-svn: 186885
2013-07-23 06:25:07 +08:00
unsigned MachOObjectFile::getAnyRelocationLength(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
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-19 02:08:55 +08:00
if (isRelocationScattered(RE))
return getScatteredRelocationLength(RE);
return getPlainRelocationLength(this, RE);
}
unsigned
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachOObjectFile::getAnyRelocationType(
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-19 02:08:55 +08:00
if (isRelocationScattered(RE))
return getScatteredRelocationType(RE);
return getPlainRelocationType(this, RE);
}
Fix Addend computation for non external relocations on Macho. llvm-svn: 180790
2013-04-30 23:40:54 +08:00
SectionRef
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-22 05:24:32 +08:00
MachOObjectFile::getAnyRelocationSection(
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
const MachO::any_relocation_info &RE) const {
Fix Addend computation for non external relocations on Macho. llvm-svn: 180790
2013-04-30 23:40:54 +08:00
if (isRelocationScattered(RE) || getPlainRelocationExternal(RE))
Change the begin and end methods in ObjectFile to match the style guide. llvm-svn: 201108
2014-02-11 04:24:04 +08:00
return *section_end();
Fix Addend computation for non external relocations on Macho. llvm-svn: 180790
2013-04-30 23:40:54 +08:00
unsigned SecNum = getPlainRelocationSymbolNum(RE) - 1;
DataRefImpl DRI;
DRI.d.a = SecNum;
return SectionRef(DRI, this);
}
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-19 02:08:55 +08:00
MachOObjectFile::LoadCommandInfo
MachOObjectFile::getFirstLoadCommandInfo() const {
MachOObjectFile::LoadCommandInfo Load;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
unsigned HeaderSize = is64Bit() ? sizeof(MachO::mach_header_64) :
sizeof(MachO::mach_header);
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-19 02:08:55 +08:00
Load.Ptr = getPtr(this, HeaderSize);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
Load.C = getStruct<MachO::load_command>(this, Load.Ptr);
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
if (Load.C.cmdsize < 8)
report_fatal_error("Load command with size < 8 bytes.");
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-19 02:08:55 +08:00
return Load;
}
MachOObjectFile::LoadCommandInfo
MachOObjectFile::getNextLoadCommandInfo(const LoadCommandInfo &L) const {
MachOObjectFile::LoadCommandInfo Next;
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
Next.Ptr = L.Ptr + L.C.cmdsize;
Next.C = getStruct<MachO::load_command>(this, Next.Ptr);
Report fatal errors instead of segfaulting/asserting on a few invalid accesses while reading MachO files. Summary: Shift an older “invalid file” test to get a consistent naming for these tests. Bugs found by afl-fuzz Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6945 llvm-svn: 226219
2015-01-16 06:52:38 +08:00
if (Next.C.cmdsize < 8)
report_fatal_error("Load command with size < 8 bytes.");
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-19 02:08:55 +08:00
return Next;
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section MachOObjectFile::getSection(DataRefImpl DRI) const {
Stop inventing symbol sizes. MachO and COFF quite reasonably only define the size for common symbols. We used to try to figure out the "size" by computing the gap from one symbol to the next. This would not be correct in general, since a part of a section can belong to no visible symbol (padding, private globals). It was also really expensive, since we would walk every symbol to find the size of one. If a caller really wants this, it can sort all the symbols once and get all the gaps ("size") in O(n log n) instead of O(n^2). On MachO this also has the advantage of centralizing all the checks for an invalid n_sect. llvm-svn: 238028
2015-05-22 23:43:00 +08:00
assert(DRI.d.a < Sections.size() && "Should have detected this earlier");
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::section>(this, Sections[DRI.d.a]);
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 MachOObjectFile::getSection64(DataRefImpl DRI) const {
Stop inventing symbol sizes. MachO and COFF quite reasonably only define the size for common symbols. We used to try to figure out the "size" by computing the gap from one symbol to the next. This would not be correct in general, since a part of a section can belong to no visible symbol (padding, private globals). It was also really expensive, since we would walk every symbol to find the size of one. If a caller really wants this, it can sort all the symbols once and get all the gaps ("size") in O(n log n) instead of O(n^2). On MachO this also has the advantage of centralizing all the checks for an invalid n_sect. llvm-svn: 238028
2015-05-22 23:43:00 +08:00
assert(DRI.d.a < Sections.size() && "Should have detected this earlier");
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::section_64>(this, Sections[DRI.d.a]);
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section MachOObjectFile::getSection(const LoadCommandInfo &L,
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-27 04:07:33 +08:00
unsigned Index) const {
const char *Sec = getSectionPtr(this, L, Index);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::section>(this, Sec);
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::section_64 MachOObjectFile::getSection64(const LoadCommandInfo &L,
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-27 04:07:33 +08:00
const char *Sec = getSectionPtr(this, L, Index);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::section_64>(this, Sec);
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::nlist
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-19 02:08:55 +08:00
MachOObjectFile::getSymbolTableEntry(DataRefImpl DRI) const {
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
const char *P = reinterpret_cast<const char *>(DRI.p);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::nlist>(this, P);
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::nlist_64
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-19 02:08:55 +08:00
MachOObjectFile::getSymbol64TableEntry(DataRefImpl DRI) const {
Use pointers to iterate over symbols. While here, don't report a dummy symbol for relocations that don't have symbols. We used to says such relocations were for the first defined symbol, but now we return end_symbols(). The llvm-readobj output change agrees with otool. llvm-svn: 180214
2013-04-25 03:47:55 +08:00
const char *P = reinterpret_cast<const char *>(DRI.p);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::nlist_64>(this, P);
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::linkedit_data_command
MachOObjectFile::getLinkeditDataLoadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::linkedit_data_command>(this, L.Ptr);
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08: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-27 04:07:33 +08:00
MachOObjectFile::getSegmentLoadCommand(const LoadCommandInfo &L) const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::segment_command>(this, L.Ptr);
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08: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-27 04:07:33 +08:00
MachOObjectFile::getSegment64LoadCommand(const LoadCommandInfo &L) const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::segment_command_64>(this, L.Ptr);
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-27 04:07:33 +08:00
}
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 08:53:40 +08:00
MachO::linker_option_command
MachOObjectFile::getLinkerOptionLoadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::linker_option_command>(this, L.Ptr);
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-27 04:07:33 +08:00
}
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-19 06:09:05 +08:00
MachO::version_min_command
MachOObjectFile::getVersionMinLoadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::version_min_command>(this, L.Ptr);
}
macho-dump: add code to print LC_ID_DYLIB load commands. I want to check them in lld. llvm-svn: 212043
2014-06-30 22:40:57 +08:00
MachO::dylib_command
MachOObjectFile::getDylibIDLoadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::dylib_command>(this, L.Ptr);
}
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-05 00:54:47 +08:00
MachO::dyld_info_command
MachOObjectFile::getDyldInfoLoadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::dyld_info_command>(this, L.Ptr);
}
MachO::dylinker_command
MachOObjectFile::getDylinkerCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::dylinker_command>(this, L.Ptr);
}
MachO::uuid_command
MachOObjectFile::getUuidCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::uuid_command>(this, L.Ptr);
}
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 15:37:02 +08:00
MachO::rpath_command
MachOObjectFile::getRpathCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::rpath_command>(this, L.Ptr);
}
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-05 00:54:47 +08:00
MachO::source_version_command
MachOObjectFile::getSourceVersionCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::source_version_command>(this, L.Ptr);
}
MachO::entry_point_command
MachOObjectFile::getEntryPointCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::entry_point_command>(this, L.Ptr);
}
Add printing the LC_ENCRYPTION_INFO load command with llvm-objdump’s -private-headers. llvm-svn: 224390
2014-12-17 07:25:52 +08:00
MachO::encryption_info_command
MachOObjectFile::getEncryptionInfoCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::encryption_info_command>(this, L.Ptr);
}
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 09:01:30 +08:00
MachO::encryption_info_command_64
MachOObjectFile::getEncryptionInfoCommand64(const LoadCommandInfo &L) const {
return getStruct<MachO::encryption_info_command_64>(this, L.Ptr);
}
Add printing the LC_SUB_FRAMEWORK load command with llvm-objdump’s -private-headers. llvm-svn: 224534
2014-12-19 03:24:35 +08:00
MachO::sub_framework_command
MachOObjectFile::getSubFrameworkCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::sub_framework_command>(this, L.Ptr);
}
macho-dump: add code to print LC_ID_DYLIB load commands. I want to check them in lld. llvm-svn: 212043
2014-06-30 22:40:57 +08:00
Add printing the LC_SUB_UMBRELLA load command with llvm-objdump’s -private-headers. llvm-svn: 224548
2014-12-19 07:13:26 +08:00
MachO::sub_umbrella_command
MachOObjectFile::getSubUmbrellaCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::sub_umbrella_command>(this, L.Ptr);
}
Add printing the LC_SUB_LIBRARY load command with llvm-objdump’s -private-headers. llvm-svn: 224607
2014-12-20 03:48:16 +08:00
MachO::sub_library_command
MachOObjectFile::getSubLibraryCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::sub_library_command>(this, L.Ptr);
}
Add printing the LC_SUB_CLIENT load command with llvm-objdump’s -private-headers. llvm-svn: 224616
2014-12-20 05:06:24 +08:00
MachO::sub_client_command
MachOObjectFile::getSubClientCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::sub_client_command>(this, L.Ptr);
}
Add printing the LC_ROUTINES load commands with llvm-objdump’s -private-headers. llvm-svn: 224627
2014-12-20 06:25:22 +08:00
MachO::routines_command
MachOObjectFile::getRoutinesCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::routines_command>(this, L.Ptr);
}
MachO::routines_command_64
MachOObjectFile::getRoutinesCommand64(const LoadCommandInfo &L) const {
return getStruct<MachO::routines_command_64>(this, L.Ptr);
}
Add printing the LC_THREAD load commands with llvm-objdump’s -private-headers. llvm-svn: 224792
2014-12-24 06:56:39 +08:00
MachO::thread_command
MachOObjectFile::getThreadCommand(const LoadCommandInfo &L) const {
return getStruct<MachO::thread_command>(this, L.Ptr);
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::any_relocation_info
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-19 02:08:55 +08:00
MachOObjectFile::getRelocation(DataRefImpl Rel) const {
Implement macho relocation iterators with section number + relocation number. This will make it possible to implement getRelocationAddress. llvm-svn: 205587
2014-04-04 07:51:28 +08:00
DataRefImpl Sec;
Sec.d.a = Rel.d.a;
uint32_t Offset;
if (is64Bit()) {
MachO::section_64 Sect = getSection64(Sec);
Offset = Sect.reloff;
} else {
MachO::section Sect = getSection(Sec);
Offset = Sect.reloff;
}
auto P = reinterpret_cast<const MachO::any_relocation_info *>(
getPtr(this, Offset)) + Rel.d.b;
return getStruct<MachO::any_relocation_info>(
this, reinterpret_cast<const char *>(P));
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::data_in_code_entry
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-07 01:20:50 +08:00
MachOObjectFile::getDice(DataRefImpl Rel) const {
const char *P = reinterpret_cast<const char *>(Rel.p);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::data_in_code_entry>(this, P);
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-07 01:20:50 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::mach_header MachOObjectFile::getHeader() const {
return getStruct<MachO::mach_header>(this, getPtr(this, 0));
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::mach_header_64 MachOObjectFile::getHeader64() const {
return getStruct<MachO::mach_header_64>(this, getPtr(this, 0));
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint32_t MachOObjectFile::getIndirectSymbolTableEntry(
const MachO::dysymtab_command &DLC,
unsigned Index) const {
uint64_t Offset = DLC.indirectsymoff + Index * sizeof(uint32_t);
return getStruct<uint32_t>(this, getPtr(this, Offset));
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::data_in_code_entry
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-27 04:07:33 +08:00
MachOObjectFile::getDataInCodeTableEntry(uint32_t DataOffset,
unsigned Index) const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
uint64_t Offset = DataOffset + Index * sizeof(MachO::data_in_code_entry);
return getStruct<MachO::data_in_code_entry>(this, getPtr(this, Offset));
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::symtab_command MachOObjectFile::getSymtabLoadCommand() const {
Update llvm-objdump’s Mach-O symbolizer code for Objective-C references. This prints disassembly comments for Objective-C references to CFStrings, Selectors, Classes and method calls. llvm-svn: 220500
2014-10-24 03:37:31 +08:00
if (SymtabLoadCmd)
return getStruct<MachO::symtab_command>(this, SymtabLoadCmd);
// If there is no SymtabLoadCmd return a load command with zero'ed fields.
MachO::symtab_command Cmd;
Cmd.cmd = MachO::LC_SYMTAB;
Cmd.cmdsize = sizeof(MachO::symtab_command);
Cmd.symoff = 0;
Cmd.nsyms = 0;
Cmd.stroff = 0;
Cmd.strsize = 0;
return Cmd;
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-19 02:08:55 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::dysymtab_command MachOObjectFile::getDysymtabLoadCommand() const {
Update llvm-objdump’s Mach-O symbolizer code for Objective-C references. This prints disassembly comments for Objective-C references to CFStrings, Selectors, Classes and method calls. llvm-svn: 220500
2014-10-24 03:37:31 +08:00
if (DysymtabLoadCmd)
return getStruct<MachO::dysymtab_command>(this, DysymtabLoadCmd);
// If there is no DysymtabLoadCmd return a load command with zero'ed fields.
MachO::dysymtab_command Cmd;
Cmd.cmd = MachO::LC_DYSYMTAB;
Cmd.cmdsize = sizeof(MachO::dysymtab_command);
Cmd.ilocalsym = 0;
Cmd.nlocalsym = 0;
Cmd.iextdefsym = 0;
Cmd.nextdefsym = 0;
Cmd.iundefsym = 0;
Cmd.nundefsym = 0;
Cmd.tocoff = 0;
Cmd.ntoc = 0;
Cmd.modtaboff = 0;
Cmd.nmodtab = 0;
Cmd.extrefsymoff = 0;
Cmd.nextrefsyms = 0;
Cmd.indirectsymoff = 0;
Cmd.nindirectsyms = 0;
Cmd.extreloff = 0;
Cmd.nextrel = 0;
Cmd.locreloff = 0;
Cmd.nlocrel = 0;
return Cmd;
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-27 04:07:33 +08:00
}
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::linkedit_data_command
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-07 01:20:50 +08:00
MachOObjectFile::getDataInCodeLoadCommand() const {
if (DataInCodeLoadCmd)
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
return getStruct<MachO::linkedit_data_command>(this, DataInCodeLoadCmd);
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-07 01:20:50 +08:00
// If there is no DataInCodeLoadCmd return a load command with zero'ed fields.
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::linkedit_data_command Cmd;
Cmd.cmd = MachO::LC_DATA_IN_CODE;
Cmd.cmdsize = sizeof(MachO::linkedit_data_command);
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-28 05:28:24 +08:00
Cmd.dataoff = 0;
Cmd.datasize = 0;
return Cmd;
}
MachO::linkedit_data_command
MachOObjectFile::getLinkOptHintsLoadCommand() const {
if (LinkOptHintsLoadCmd)
return getStruct<MachO::linkedit_data_command>(this, LinkOptHintsLoadCmd);
// If there is no LinkOptHintsLoadCmd return a load command with zero'ed
// fields.
MachO::linkedit_data_command Cmd;
Cmd.cmd = MachO::LC_LINKER_OPTIMIZATION_HINT;
Cmd.cmdsize = sizeof(MachO::linkedit_data_command);
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
Cmd.dataoff = 0;
Cmd.datasize = 0;
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-07 01:20:50 +08:00
return Cmd;
}
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 08:20:14 +08:00
ArrayRef<uint8_t> MachOObjectFile::getDyldInfoRebaseOpcodes() const {
if (!DyldInfoLoadCmd)
return ArrayRef<uint8_t>();
MachO::dyld_info_command DyldInfo
= getStruct<MachO::dyld_info_command>(this, DyldInfoLoadCmd);
const uint8_t *Ptr = reinterpret_cast<const uint8_t*>(
getPtr(this, DyldInfo.rebase_off));
return ArrayRef<uint8_t>(Ptr, DyldInfo.rebase_size);
}
ArrayRef<uint8_t> MachOObjectFile::getDyldInfoBindOpcodes() const {
if (!DyldInfoLoadCmd)
return ArrayRef<uint8_t>();
MachO::dyld_info_command DyldInfo
= getStruct<MachO::dyld_info_command>(this, DyldInfoLoadCmd);
const uint8_t *Ptr = reinterpret_cast<const uint8_t*>(
getPtr(this, DyldInfo.bind_off));
return ArrayRef<uint8_t>(Ptr, DyldInfo.bind_size);
}
ArrayRef<uint8_t> MachOObjectFile::getDyldInfoWeakBindOpcodes() const {
if (!DyldInfoLoadCmd)
return ArrayRef<uint8_t>();
MachO::dyld_info_command DyldInfo
= getStruct<MachO::dyld_info_command>(this, DyldInfoLoadCmd);
const uint8_t *Ptr = reinterpret_cast<const uint8_t*>(
getPtr(this, DyldInfo.weak_bind_off));
return ArrayRef<uint8_t>(Ptr, DyldInfo.weak_bind_size);
}
ArrayRef<uint8_t> MachOObjectFile::getDyldInfoLazyBindOpcodes() const {
if (!DyldInfoLoadCmd)
return ArrayRef<uint8_t>();
MachO::dyld_info_command DyldInfo
= getStruct<MachO::dyld_info_command>(this, DyldInfoLoadCmd);
const uint8_t *Ptr = reinterpret_cast<const uint8_t*>(
getPtr(this, DyldInfo.lazy_bind_off));
return ArrayRef<uint8_t>(Ptr, DyldInfo.lazy_bind_size);
}
ArrayRef<uint8_t> MachOObjectFile::getDyldInfoExportsTrie() const {
if (!DyldInfoLoadCmd)
return ArrayRef<uint8_t>();
MachO::dyld_info_command DyldInfo
= getStruct<MachO::dyld_info_command>(this, DyldInfoLoadCmd);
const uint8_t *Ptr = reinterpret_cast<const uint8_t*>(
getPtr(this, DyldInfo.export_off));
return ArrayRef<uint8_t>(Ptr, DyldInfo.export_size);
}
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 07:35:45 +08:00
ArrayRef<uint8_t> MachOObjectFile::getUuid() const {
if (!UuidLoadCmd)
return ArrayRef<uint8_t>();
[Object] Fix MachO's getUuid to return a pointer into the object instead of a dangling ArrayRef. This works because uuid's are always little endian so it's not swapped. Fixes use-after-return reported by asan. llvm-svn: 220567
2014-10-24 23:52:05 +08:00
// Returning a pointer is fine as uuid doesn't need endian swapping.
const char *Ptr = UuidLoadCmd + offsetof(MachO::uuid_command, uuid);
return ArrayRef<uint8_t>(reinterpret_cast<const uint8_t *>(Ptr), 16);
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 07:35:45 +08: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 08:20:14 +08: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-27 04:07:33 +08:00
StringRef MachOObjectFile::getStringTableData() const {
Move everything depending on Object/MachOFormat.h over to Support/MachO.h. llvm-svn: 189728
2013-09-01 12:28:48 +08:00
MachO::symtab_command S = getSymtabLoadCommand();
return getData().substr(S.stroff, S.strsize);
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-27 04:07:33 +08: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-19 02:08:55 +08:00
bool MachOObjectFile::is64Bit() const {
return getType() == getMachOType(false, true) ||
[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-16 03:35:22 +08:00
getType() == getMachOType(true, true);
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-19 02:08:55 +08:00
}
void MachOObjectFile::ReadULEB128s(uint64_t Index,
SmallVectorImpl<uint64_t> &Out) const {
DataExtractor extractor(ObjectFile::getData(), true, 0);
uint32_t offset = Index;
uint64_t data = 0;
while (uint64_t delta = extractor.getULEB128(&offset)) {
data += delta;
Out.push_back(data);
}
}
llvm-objdump: don't print relocations in non-relocatable files. This matches the behavior of GNU objdump. llvm-svn: 215844
2014-08-18 03:09:37 +08:00
bool MachOObjectFile::isRelocatableObject() const {
return getHeader().filetype == MachO::MH_OBJECT;
}
Use std::unique_ptr to make the ownership explicit. llvm-svn: 214377
2014-07-31 11:12:45 +08:00
ErrorOr<std::unique_ptr<MachOObjectFile>>
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
ObjectFile::createMachOObjectFile(MemoryBufferRef Buffer) {
StringRef Magic = Buffer.getBuffer().slice(0, 4);
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-13 05:46:39 +08:00
std::error_code EC;
Replace OwningPtr<T> with std::unique_ptr<T>. This compiles with no changes to clang/lld/lldb with MSVC and includes overloads to various functions which are used by those projects and llvm which have OwningPtr's as parameters. This should allow out of tree projects some time to move. There are also no changes to libs/Target, which should help out of tree targets have time to move, if necessary. llvm-svn: 203083
2014-03-06 13:51:42 +08:00
std::unique_ptr<MachOObjectFile> Ret;
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-19 02:08:55 +08:00
if (Magic == "\xFE\xED\xFA\xCE")
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
Ret.reset(new MachOObjectFile(Buffer, false, false, EC));
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-19 02:08:55 +08:00
else if (Magic == "\xCE\xFA\xED\xFE")
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
Ret.reset(new MachOObjectFile(Buffer, true, false, EC));
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-19 02:08:55 +08:00
else if (Magic == "\xFE\xED\xFA\xCF")
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
Ret.reset(new MachOObjectFile(Buffer, false, true, EC));
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-19 02:08:55 +08:00
else if (Magic == "\xCF\xFA\xED\xFE")
Don't own the buffer in object::Binary. Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
2014-08-20 02:44:46 +08:00
Ret.reset(new MachOObjectFile(Buffer, true, true, EC));
Pass a std::unique_ptr& to the create??? methods is lib/Object. This makes the buffer ownership on error conditions very natural. The buffer is only moved out of the argument if an object is constructed that now owns the buffer. llvm-svn: 211546
2014-06-24 06:00:37 +08:00
else
Be a bit more consistent about using ErrorOr when constructing Binary objects. The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. llvm-svn: 199770
2014-01-22 07:06:54 +08:00
return object_error::parse_failed;
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-19 02:08:55 +08:00
Be a bit more consistent about using ErrorOr when constructing Binary objects. The constructors of classes deriving from Binary normally take an error_code as an argument to the constructor. My original intent was to change them to have a trivial constructor and move the initial parsing logic to a static method returning an ErrorOr. I changed my mind because: * A constructor with an error_code out parameter is extremely convenient from the implementation side. We can incrementally construct the object and give up when we find an error. * It is very efficient when constructing on the stack or when there is no error. The only inefficient case is where heap allocating and an error is found (we have to free the memory). The result is that this is a much smaller patch. It just standardizes the create* helpers to return an ErrorOr. Almost no functionality change: The only difference is that this found that we were trying to read past the end of COFF import library but ignoring the error. llvm-svn: 199770
2014-01-22 07:06:54 +08:00
if (EC)
return EC;
Use std::unique_ptr to make the ownership explicit. llvm-svn: 214377
2014-07-31 11:12:45 +08:00
return std::move(Ret);
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-19 02:08:55 +08:00
}