Age | Commit message (Collapse) | Author | Files | Lines |
|
This is failing on Windows bots due to path separator normalization.
This reverts commit 042c23506869b4ae9a49d2c4bc5ea6e6baeabe78.
|
|
Add Thread Local Storage Local Exec support to LLD. This is to support PC Relative addressing of Local Exec.
The patch teaches LLD to handle:
```
paddi r9, r13, x1@tprel
```
The relocation is:
```
R_PPC_TPREL34
```
Reviewed By: NeHuang, MaskRay
Differential Revision: https://reviews.llvm.org/D86608
|
|
With https://reviews.llvm.org/D87537 we made it an error
to import or export a mutable global with the +mutable-globals
feature present. However the scan was of the entire symbol
table rather than just the imports or exports and the filter
didn't match exaclyt meaning the `__stack_pointer` (a mutable
global) was always triggering with error when the `--export-all`
flag was used.
This also revealed that we didn't have any test coverage for
the `--export-all` flag.
This change fixes the current breakage on the emscripten-releases
roller.
Differential Revision: https://reviews.llvm.org/D87663
|
|
This is a follow up to c1f2fb5184ca.
|
|
`ELFFile<ELFT>` has many methods that take pointers,
though they assume that arguments are never null and
hence could take references instead.
This patch performs such clean-up.
Differential revision: https://reviews.llvm.org/D87385
|
|
This addresses test failure revealed by 042c23506869.
|
|
The motivation for this is ld.lld --help targeting MinGW which
currently prints help for the ELF backend unless -m i386pe{,p} is
added. This confuses build systems that grep through linker help to
find supported flags.
This matches LD from Binutils which always prints help for MinGW
when configured to target it.
After this change, the backend can still be overridden to any
supported ELF/MinGW target by using correct -m <arch>.
Differential Revision: https://reviews.llvm.org/D87418
|
|
This feature already exists but was limited to function
symbols.
Differential Revision: https://reviews.llvm.org/D87666
|
|
tool (and lesser of layering detection)
Differential Revision: https://reviews.llvm.org/D86762
|
|
PPC64 thunk range errors
Prefer `errorOrWarn` to `fatal` for recoverable errors and graceful degradation
when --noinhibit-exec is specified.
Mention the destination symbol, otherwise the diagnostic is not really actionable.
Two errors are not tested but the patch does not intend to add the coverage.
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D87486
|
|
Differential Revision: https://reviews.llvm.org/D77187
|
|
`mutable-globals` feature
Also add the +mutable-globals features in clang when
building with `-fPIC` since the linker will generate mutable
globals imports and exports in that case.
Differential Revision: https://reviews.llvm.org/D87537
|
|
Differential Revision: https://reviews.llvm.org/D87536
|
|
This adds and optional ", immutable" to the end of a `.globaltype`
declaration. I would have prefered to match the `.wat` syntax
where immutable is the default and `mut` is the signifier for
mutable globals. Sadly changing the default would break backwards
compat with existing assembly in the wild so I think its best
to stick with this approach.
Differential Revision: https://reviews.llvm.org/D87515
|
|
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D87483
|
|
Why are they mutable? :)
|
|
This addresses an issue introduced in c4d7536136b3.
|
|
This matches the changes made to handling of zlib done in 10b1b4a
where we rely on find_package and the imported target rather than
manually appending the library and include paths. The use of
LLVM_LIBXML2_ENABLED has been replaced by LLVM_ENABLE_LIBXML2
thus reducing the number of variables.
Differential Revision: https://reviews.llvm.org/D84563
|
|
MarkLive::scanEhFrameSection is used to retain personality/LSDA
functions when --gc-sections is enabled.
Improve its performance by only iterating over the .eh_frame relocations
that need to be resolved for an EhSectionPiece. This optimization makes
the same assumption as elsewhere in LLD that the .eh_frame relocations
are sorted by r_offset.
This appears to be a performance regression introduced in commit
e6c24299d237 (https://reviews.llvm.org/D59800).
This change has been seen to reduce link time by up to ~50%.
Differential Revision: https://reviews.llvm.org/D87245
|
|
LLVM has bumped the minimum required CMake version to 3.13.4, so this has become dead code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D87189
|
|
|
|
Currently we treat SHT_RISCV_ATTRIBUTES like a normal section and
concatenate all such input sections, yielding invalid output unless only
a single attributes section is present in the input. Instead, pick the
first as with SHT_ARM_ATTRIBUTES. We do not currently need to condition
our behaviour on the contents, unlike Arm. In future, we should both do
stricter validation of the input and merge all sections together to
ensure we have, for example, the full arch string requirement, but this
rudimentary implementation is good enough for most common cases.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86309
|
|
|
|
ppc64-pcrel-long-branch-error.s
Following 97febb1, fix the out-of-memory error associated with buffering the output
in-memory by writing to an allocated file with the minimum offset and running it
on ppc system-linux only.
Peer reviewed by: nemanjai
|
|
|
|
The PE/DLL format has a limit on 64k exported symbols per DLL; make
sure to check this.
Differential Revision: https://reviews.llvm.org/D86701
|
|
Following 0becc27ebfec, `ppc64-pcrel-long-branch-error.s` fails in some
environments with out-of-memory errors associated with buffering the
output in-memory. Since the alternative of writing to an allocated file
is also known to cause problems, we will disable the test
unconditionally (pending a mechanism to disable the test selectively).
|
|
Fix the time out test failure on lld-x86_64-freebsd build bot.
Peer reviewed by: stefanp, nemanjai
|
|
In this patch, a pc-rel based long branch thunk is added for the local
call protocol that caller and callee does not use TOC.
Reviewed By: sfertile, nemanjai
Differential Revision: https://reviews.llvm.org/D86706
|
|
Since it's always true
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86749
|
|
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86746
|
|
Found such a relocation while testing some real world programs.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86642
|
|
We can have GOT_LOAD relocations that reference `__dso_handle`.
However, our binding opcode encoder doesn't support binding to the DSOHandle
symbol. Instead of adding support for that, I decided it would be cleaner to
implement GOT_LOAD relaxation since `__dso_handle`'s location is always
statically known.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86641
|
|
These opcodes tell dyld to coalesce the overridden weak dysyms to this
particular symbol definition.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86575
|
|
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86574
|
|
Since there is no "weak lazy" lookup, function calls to weak symbols are
always non-lazily bound. We emit both regular non-lazy bindings as well
as weak bindings, in order that the weak bindings may overwrite the
non-lazy bindings if an appropriate symbol is found at runtime. However,
the bound addresses will still be written (non-lazily) into the
LazyPointerSection.
Reviewed By: #lld-macho, smeenai
Differential Revision: https://reviews.llvm.org/D86573
|
|
It seems to be failing on some Google Buildbots.
This diff also includes a minor fix for the install name of one of
libSystem's re-exports. I don't think it's the cause of the test
failure, though. The wrong install name just meant that the symbol
lookup failure would still happen, but it would have been caused by the
re-export not being found, instead of the arch failing to match.
Differential Revision: https://reviews.llvm.org/D86728
|
|
IMAGE_COMDAT_SELECT_SAME_SIZE
Binutils generated sections seem to be padded to a multiple of 16 bytes,
but the aux section definition contains the original, unpadded section
length.
The size check used for IMAGE_COMDAT_SELECT_SAME_SIZE previously
only checked the size of the section itself. When checking the
currently processed object file against the previously chosen
comdat section, we easily have access to the aux section definition
of the currently processed section, but we have to iterate over the
symbols of the previously selected object file to find the section
definition of the previously picked section. (We don't want to
inflate SectionChunk to carry more data, for something that is only
needed in corner cases.) Only do this when the mingw flag is set.
This fixes statically linking clang-built C++ object files against
libstdc++ built with GCC, if the object files contain e.g. typeinfo.
Differential Revision: https://reviews.llvm.org/D86659
|
|
This matches lld-link's own default.
Add a new command line option --no-dynamicbase for disabling it.
(Unfortunately, GNU ld doesn't yet have a matching --no-dynamicbase
option, as that's the default there.)
Differential Revision: https://reviews.llvm.org/D86654
|
|
Differential Revision: https://reviews.llvm.org/D86639
|
|
Whilst reviewing some internal testing, I noticed a couple of holes in
coverage of mergeable sections containing symbols. This patch addresses
these holes:
1) Show that mid-piece symbols have their values updated properly when
pieces are merged.
2) Show the behaviour of symbols in mergeable pieces when --gc-sections
is enabled.
Reviewed by: grimar, MaskRay
Differential Revision: https://reviews.llvm.org/D86543
|
|
Summary: It was passing on my local machine due to previously-written
files cached in the test output folder.
|
|
Differential Revision: https://reviews.llvm.org/D86640
|
|
Previously, we were only emitting regular bindings to weak
dynamic symbols; this diff adds support for the weak bindings too, which
can overwrite the regular bindings at runtime. We also treat weak
defined global symbols similarly -- since they can also be interposed at
runtime, they need to be treated as potentially dynamic symbols.
Note that weak bindings differ from regular bindings in that they do not
specify the dylib to do the lookup in (i.e. weak symbol lookup happens
in a flat namespace.)
Differential Revision: https://reviews.llvm.org/D86572
|
|
Previously, the BindingEntry struct could only store bindings to offsets
within InputSections. Since the GOTSection and TLVPointerSections are
OutputSections, I handled those in a separate code path. However, this
makes it awkward to support weak bindings properly without code
duplication. This diff allows BindingEntries to point directly to
OutputSections, simplifying the upcoming weak binding implementation.
Along the way, I also converted a bunch of functions taking references
to symbols to take pointers instead. Given how much casting we do for
Symbol (especially in the upcoming weak binding diffs), it's cleaner
this way.
Differential Revision: https://reviews.llvm.org/D86571
|
|
It's roughly like -force_load with some filtering.
Differential Revision: https://reviews.llvm.org/D86181
|
|
The re-exports list in a TAPI document can either refer to other inlined
TAPI documents, or to on-disk files (which may themselves be TBD or
regular files.) Similarly, the re-exports of a regular dylib can refer
to a TBD file.
Differential Revision: https://reviews.llvm.org/D85404
|
|
Two things needed fixing for that to work:
1. getName() no longer returns null for DylibFiles constructed from TAPIs
2. markSubLibrary() now accepts .tbd as a possible extension
Differential Revision: https://reviews.llvm.org/D86180
|
|
This matches ld64's behavior
Differential Revision: https://reviews.llvm.org/D85992
|
|
Basically copied from ELF driver.
Differential Revision: https://reviews.llvm.org/D86512
|