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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224485 91177308-0d34-0410-b5e6-96231b3b80d8
This adds the printing of more load commands, so that the normal load commands
in a typical X86 Mach-O executable can all be printed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217172 91177308-0d34-0410-b5e6-96231b3b80d8
MachOObjectFile in lib/Object currently has no support for parsing the rebase,
binding, and export information from the LC_DYLD_INFO load command in final
linked mach-o images. This patch adds support for parsing the exports trie data
structure. It also adds an option to llvm-objdump to dump that export info.
I did the exports parsing first because it is the hardest. The information is
encoded in a trie structure, but the standard ObjectFile way to inspect content
is through iterators. So I needed to make an iterator that would do a
non-recursive walk through the trie and maintain the concatenation of edges
needed for the current string prefix.
I plan to add similar support in MachOObjectFile and llvm-objdump to
parse/display the rebasing and binding info too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216808 91177308-0d34-0410-b5e6-96231b3b80d8
universal file. This also includes support for -arch all, selecting the host
architecture by default from a universal file and checking if -arch is used
with a standard Mach-O it matches that architecture.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212054 91177308-0d34-0410-b5e6-96231b3b80d8
This is a first step in seeing if it is possible to make llvm-nm produce
the same output as darwin's nm(1). Darwin's default format is bsd but its
-m output prints the longer Mach-O specific details. For now I added the
"-format darwin" to do this (whos name may need to change in the future).
As there are other Mach-O specific flags to nm(1) which I'm hoping to add some
how in the future. But I wanted to see if I could get the correct output for
-m flag using llvm-nm and the libObject interfaces.
I got this working but would love to hear what others think about this approach
to getting object/format specific details printed with llvm-nm.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210285 91177308-0d34-0410-b5e6-96231b3b80d8
When pruning superfluous MachO structure definitions, I chose to keep
the most generically useful which is why Support's definitions won over
the ones in MC.
However, the MC copy had some useful comments describing some of the
field values.
Bring these back to the copy in Support. While doing this, fill in some
of the underdocumented definitions as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209066 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205090 91177308-0d34-0410-b5e6-96231b3b80d8
Another part of the ARM64 backend (so tests will be following soon).
This is currently used by the linker to relax adrp/ldr pairs into nops
where possible, though could well be more broadly applicable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205084 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
llvm/MC/MCSectionMachO.h and llvm/Support/MachO.h both had the same
definitions for the section flags. Instead, grab the definitions out of
support.
No functionality change.
Reviewers: grosbach, Bigcheese, rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2998
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203211 91177308-0d34-0410-b5e6-96231b3b80d8
The underlying type of all plain enums in MSVC is 'int', even if the
enumerator contains large 32-bit unsigned values or values greater than
UINT_MAX. The only way to get a large or unsigned enum type is to
request it explicitly with the C++11 strong enum types feature.
However, since LLVM isn't C++11 yet, I had to add a conditional
LLVM_ENUM_INT_TYPE to Compiler.h to control its usage.
The motivating true positive for this change is compiling PointerIntPair
with MSVC for win64. The PointerIntMask value is supposed to be pointer
sized value of all ones with some low zeros. Instead, it's truncated to
32-bits! We are only saved later because it is sign extended back in
the AND with int64_t, and we happen to want all ones.
This silences lots of -Wmicrosoft warnings during a clang self-host
targeting Windows.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191241 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189314 91177308-0d34-0410-b5e6-96231b3b80d8
to Parse mach-o files. All defines have been renamed to not conflict with
#defines in mach header files, all structures were left named the same but
are in the llvm::MachO namespace.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@108953 91177308-0d34-0410-b5e6-96231b3b80d8
