| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 284734
|
|
|
|
| |
llvm-svn: 281260
|
|
|
|
|
|
|
| |
It wasn't harmful, just goofy. It's weird to see how this has
fallen through the crack without anybody noticing for so long.
llvm-svn: 281148
|
|
|
|
| |
llvm-svn: 280753
|
|
|
|
| |
llvm-svn: 280733
|
|
|
|
|
|
|
| |
Adopt r280128 in lld, specializing ilist_alloc_traits rather than
reinventing the wheel.
llvm-svn: 280566
|
|
|
|
| |
llvm-svn: 279458
|
|
|
|
|
|
|
| |
Use ilist_half_embedded_sentinel_traits for the list of
lld::mach_o::normalized::TrieEdge, rather than duplicating the code.
llvm-svn: 278523
|
|
|
|
|
|
| |
It only makes sense to set on N_NO_DEAD_STRIP on a relocatable object file. Otherwise the bits aren't useful for anything. Matches the ld64 behaviour.
llvm-svn: 278419
|
|
|
|
|
|
|
|
|
| |
We should be using one of BIND_OPCODE_SET_DYLIB_SPECIAL_IMM, BIND_OPCODE_SET_DYLIB_ORDINAL_IMM,
and BIND_OPCODE_SET_DYLIB_ORDINAL_ULEB depending on whether ordinals are <= 0, <= 15, > 15.
This matches the behaviour of ld64.
llvm-svn: 278407
|
|
|
|
|
|
|
|
|
|
|
|
| |
as last time.
We already had logic for binding opcodes had the same addend as last time. This adds
the cases where the ordinal, symbol name, type, and segment offsets are the same as
the last emitted ordinal.
This gets us one step closer to emitting rebase opcodes as compressed as ld64 can manage.
llvm-svn: 278405
|
|
|
|
|
|
| |
This matches the behaviour of ld64 when looking at the alignment of the stubs section in the final image.
llvm-svn: 278398
|
|
|
|
|
|
|
|
|
|
|
| |
Currently we do this when an atom is used, but we need to do it when a
dylib is referenced on the cmdline as this matches ld64.
This fixes much confusion over which maps are indexed with installName
vs path. There is likely other confusion so i'll be seeing if i can remove
path() completely in a future commit as path() shouldn't really be needed by anyone.
llvm-svn: 278396
|
|
|
|
|
|
|
|
| |
A version of 0x1000 is 0.16.0, not 1.0.0 as the comment said. Fix the
value to match the comment, and also the one test case which had this
wrong.
llvm-svn: 278381
|
|
|
|
|
|
|
|
|
|
| |
Using vmsize to populate this file works when outputing MachO images, but fails
when outputting relocatable objects. This patch fixes the computation to use
file offsets, which works for both output types.
Fixes <rdar://problem/27727666>
llvm-svn: 278297
|
|
|
|
|
|
|
| |
This matches the behaviour of ld64 which initializes the string table with
' ' then '\0'. lld only had the '\0' and needed the ' '.
llvm-svn: 278071
|
|
|
|
|
|
|
|
| |
The export trie was being emitted in the order the nodes were
added to the vector, but instead needs to be visited in the order
that the nodes are traversed. This matches the behaviour of ld64.
llvm-svn: 277869
|
|
|
|
|
|
|
|
|
|
|
| |
The MachO debug support code (committed in r276935) occasionally needs to
allocate string copies, and was doing so by creating std::strings on a
BumpPtrAllocator. The strings were untracked, so the destructors weren't being
run and we were leaking the memory when the allocator was thrown away. Since
it's easier than tracking the strings, this patch switches the copies to char
buffers allocated directly in the bump-ptr allocator.
llvm-svn: 277208
|
|
|
|
|
|
| |
r276935.
llvm-svn: 276944
|
|
|
|
|
|
| |
copies.
llvm-svn: 276935
|
|
|
|
| |
llvm-svn: 276928
|
|
|
|
|
|
|
|
|
| |
This patch causes LLD to build stabs debugging symbols for files containing
DWARF debug info, and to propagate existing stabs symbols for object files
built using '-r' mode. This enables debugging of binaries generated by LLD
from MachO objects.
llvm-svn: 276921
|
|
|
|
|
|
|
| |
This enables proper recognition of debug sections by attribute, which will be
used in the near future by test-cases for MachO debugging support.
llvm-svn: 276770
|
|
|
|
|
|
| |
This method just duplicates the functionality of SimpleFile::defined().
llvm-svn: 274048
|
|
|
|
| |
llvm-svn: 273917
|
|
|
|
|
|
|
|
|
|
| |
These references are used to implement MachO/x64-64 subtractor relocations
where the minuend is being fixed up, rather than the subtrahend. The 64-bit
version was not previously supported, the 32-bit version was partially
implemented but contained bugs not caught by existing test cases. This
patch fixes both functionality and test coverage.
llvm-svn: 273759
|
|
|
|
|
|
| |
No functionality change intended.
llvm-svn: 271686
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D19735
llvm-svn: 268093
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266596
|
|
|
|
|
|
| |
Suggested by Dave Blaikie in review of r265447. Thanks Dave!
llvm-svn: 265566
|
|
|
|
|
|
| |
This should fix the failures on the LLD bots caused by r265446.
llvm-svn: 265477
|
|
|
|
|
|
|
|
|
|
|
|
| |
NFC"
This reverts commit r264945.
The commit only removed an unreachable in a method with a covered switch, but
GCC is likely to warn on this, and the coding standards recommend just leaving
in the unreachable.
llvm-svn: 264983
|
|
|
|
| |
llvm-svn: 264981
|
|
|
|
|
|
|
|
|
|
|
|
| |
These methods weren't really throwing errors. The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file. All of the callers
also ignored errors and just used the returned path if one was available.
Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.
llvm-svn: 264979
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264978
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264977
|
|
|
|
|
|
|
|
| |
These methods were responsible for some of the few remaining calls
to llvm::errorCodeToError. Converting them makes us have more Error's
in the api and fewer error_code's.
llvm-svn: 264974
|
|
|
|
| |
llvm-svn: 264973
|
|
|
|
|
|
|
| |
This converts almost all of the error handling in atom creation
to llvm::Error instead of std::error_code.
llvm-svn: 264968
|
|
|
|
|
|
|
| |
This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.
llvm-svn: 264961
|
|
|
|
| |
llvm-svn: 264945
|
|
|
|
|
|
|
| |
This updates most of the file handling methods in the linking context and
resolver to use the new API.
llvm-svn: 264924
|
|
|
|
|
|
|
| |
Pretty mechanical change here. Just replacing all the std::error_code() with
llvm::Error() and make_dynamic_error_code with make_error<GenericError>
llvm-svn: 264917
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a GenericError class to lld/Core which can carry a string. This is
analygous to the dynamic_error we currently use in lld/Core.
Use this GenericError instead of make_dynamic_error_code. Also, provide
an implemention of GenericError::convertToErrorCode which for now converts
it in to the dynamic_error_code we used to have. This will go away once
all the APIs are converted.
llvm-svn: 264910
|
|
|
|
|
|
|
|
|
|
|
| |
searchArchivesToOverrideTentativeDefinitions and
searchSharedLibrariesToOverrideTentativeDefinitions are always false.
For the dead flags, we have a fairly large amount of code which is
never be executed.
http://reviews.llvm.org/D17791
llvm-svn: 264653
|
|
|
|
|
|
| |
Suggested by David Blaikie in response to r264234.
llvm-svn: 264311
|
|
|
|
|
|
|
|
|
| |
The stack-size.yaml test had an empty atom content array. This is
legal, but asking a BumpPtrAllocator for 0 sized data may not be
legal. Instead just avoid requesting any data when we can just return
an empty ArrayRef instead.
llvm-svn: 264234
|
|
|
|
|
|
|
|
|
| |
Its possible for file to have no entry atom which means that there
is no atom to check for being a thumb function. Instead just skip
the thumb check and set the entry address to 0, which matches the
current behaviour of getting a default initialised int from a map.
llvm-svn: 264233
|
|
|
|
|
|
|
| |
On a 32-bit output, we may write LC_MAIN (which contains a uint64_t) to
an unaligned address. This changes it to use a memcpy instead which is UB safe.
llvm-svn: 264232
|
|
|
|
|
|
|
|
|
|
|
| |
We were casting a potentially unaligned pointer to uint32_t and
dereferencing. As the pointer ultimately comes from the object file,
there's no way to guarantee alignment, so use the little32_t read instead.
Also, little32_t knows about endianness, so in theory this may have broken on
big endian machines.
llvm-svn: 264231
|