| Age | Commit message (Collapse) | Author |
|---|
|
llvm-svn: 215224
|
|
llvm-svn: 215219
|
|
llvm-svn: 215218
|
|
llvm-svn: 215216
|
|
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
|
|
llvm-svn: 214377
|
|
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
|
|
llvm-svn: 213478
|
|
llvm-svn: 213361
|
|
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
|
|
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
|
|
MSVC was warning on a switch containing only default labels. In this
instance, it looks like it uncovered a real bug. :)
llvm-svn: 212062
|
|
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
|
|
I want to check them in lld.
llvm-svn: 212043
|
|
Temporarily back out commits r211749, r211752 and r211754.
llvm-svn: 211814
|
|
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.
small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.
This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.
The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.
llvm-svn: 211749
|
|
MachO files using the GDB JIT debugging interface.
Patch by Keno Fischer. Thanks Keno!
llvm-svn: 211652
|
|
Once the objects are constructed, they own the buffer. Passing a unique_ptr
makes that clear.
llvm-svn: 211595
|
|
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
|
|
This allows us to just use a std::unique_ptr to store the pointer to the buffer.
The flip side is that they have to support releasing the buffer back to the
caller.
Overall this looks like a more efficient and less brittle api.
llvm-svn: 211542
|
|
llvm-svn: 211383
|
|
sys::swapByteOrder()
llvm-svn: 210980
|
|
The next commit will add swapByteOrder(), acting in-place
llvm-svn: 210973
|
|
llvm-svn: 210871
|
|
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
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
|
|
This makes LLVM create N_INDR aliases (to be resolved by the linker) when
appropriate.
rdar://problem/15125513
llvm-svn: 209894
|
|
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
|
|
Failing Tests (2):
LLVM :: ExecutionEngine/MCJIT/stubs-sm-pic.ll
LLVM :: ExecutionEngine/MCJIT/stubs.ll
llvm-svn: 209236
|
|
for undefined symbols. Allowing llvm-nm to print spaces instead of 0’s for
the value of undefined symbols in Mach-O files.
llvm-svn: 209235
|
|
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
|
|
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
|
|
instead of comparing to nullptr.
llvm-svn: 206252
|
|
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
|
|
With that, fix the symbolizer to work with any ELF file.
llvm-svn: 205588
|
|
This will make it possible to implement getRelocationAddress.
llvm-svn: 205587
|
|
llvm-svn: 205581
|
|
llvm-svn: 205577
|
|
This has the following advantages:
* Less code.
* The old ELF implementation was wrong for non-relocatable objects.
* The old ELF implementation (and I think MachO) was wrong for thumb.
No current testcase since this is only used from MCJIT and it only uses
relocatable objects and I don't think it supports thumb yet.
llvm-svn: 205508
|
|
All existing users explicitly ask for an address or a file offset.
llvm-svn: 205503
|
|
This reverts commit r205479.
It turns out that nm does use addresses, it is just that every reasonable
relocatable ELF object has sections with address 0. I have no idea if those
exist in reality, but it at least it shows that llvm-nm should use the name
address.
The added test was includes an unusual .o file with non 0 section addresses. I
created it by hacking ELFObjectWriter.cpp.
Really sorry for the churn.
llvm-svn: 205493
|
|
What llvm-nm prints depends on the file format. On ELF for example, if the
file is relocatable, it prints offsets. If it is not, it prints addresses.
Since it doesn't really need to care what it is that it is printing, use the
generic term value.
Fix or implement getSymbolValue to keep llvm-nm working.
llvm-svn: 205479
|
|
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
|
|
entry at a time.
Some targets require more than one relocation entry to perform a relocation.
This change allows processRelocationRef to process more than one relocation
entry at a time by passing the relocation iterator itself instead of just
the relocation entry.
Related to <rdar://problem/16199095>
llvm-svn: 204439
|
|
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
|
|
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3081
llvm-svn: 204031
|
|
Summary:
This adds ObjectFile::section_iterator_range, that allows to write
range-based for-loops running over all sections of a given file.
Several files from lib/ are converted to the new interface. Similar fixes
should be applied to a variety of llvm-* tools.
Reviewers: rafael
Reviewed By: rafael
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3069
llvm-svn: 203799
|
|
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
|
|
llvm-svn: 202957
|
|
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
|
