This reverts commit b5d0bf9b9853688d34290fafdd31c95aca58f624.
The original commit is causing 10 test failures on multiple bots, reverting to get back to green.
ld64 emits them in address order but not in alphabetical order. This
sorting is particularly expensive for dead-stripped symbols (which don't
need to be sorted at all, unlike live symbols that need to be sorted by
address).
Timings for chromium_framework_less_dwarf (with the `-map` flag added to
the response file) on my 16-core Mac Pro:
base diff difference (95% CI)
sys_time 1.997 ± 0.038 2.004 ± 0.028 [ -0.6% .. +1.3%]
user_time 8.698 ± 0.085 8.167 ± 0.070 [ -6.6% .. -5.6%]
wall_time 7.965 ± 0.114 7.715 ± 0.347 [ -5.1% .. -1.2%]
samples 25 23
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D136536
Mach-O ld64 supports -w to suppress warnings. GNU ld 2.40 will support the
option as well (https://sourceware.org/bugzilla/show_bug.cgi?id=29654).
This feature has some small value. E.g. when analyzing a large executable with
relocation overflow issues, we may use --noinhibit-exec --emit-relocs to get an
output file with static relocations despite relocation overflow issues. -w can
significantly improve the link time as printing the massive warnings is slow.
Reviewed By: peter.smith
Differential Revision: https://reviews.llvm.org/D136569
I love C++17!
chromium_framework_less_dwarf on my 16-core Mac Pro shows no stat sig change in wall time but a slight decrease in user time:
```
base diff difference (95% CI)
sys_time 1.759 ± 0.037 1.761 ± 0.033 [ -0.9% .. +1.1%]
user_time 4.920 ± 0.043 4.886 ± 0.051 [ -1.2% .. -0.2%]
wall_time 5.950 ± 0.117 5.900 ± 0.116 [ -1.8% .. +0.2%]
samples 26 37
```
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D136518
... instead of mapping them to the intermediate object file.
This matches ld64.
Reviewed By: #lld-macho, Roger
Differential Revision: https://reviews.llvm.org/D136380
```
template <typename T> struct A {
A() {}
int value = 0;
};
template <typename Value> struct B {
static A<int> a;
};
template <typename Value> A<int> B<Value>::a;
inline int foo() {
return B<int>::a.value;
}
```
```
clang++ -c -fno-pic a.cc -o weak.o
g++ -c -fno-pic a.cc -o unique.o # --enable-gnu-unique-object
# Duplicate symbol error. In postParse, we do not check `sym.binding`
ld.lld -e 0 weak.o unique.o
```
Mixing GCC and Clang object files in this case is not ideal. .bss._ZGVN1BIiE1aE
has different COMDAT groups. It appears to work in practice because the guard
variable prevents harm due to double initialization.
For the linker, we just stick with the rule that a weak binding does not cause
"duplicate symbol" errors.
Close https://github.com/llvm/llvm-project/issues/58232
Differential Revision: https://reviews.llvm.org/D136381
Add some checks around this combination of flags
Also, honor `--global-base` when specified in `--stack-first` mode
rather than ignoring it. But error out if the specified base preseeds
the end of the stack.
Differential Revision: https://reviews.llvm.org/D136117
This matches ld64's behavior.
I also extended the icf-stabs.s test to demonstrate that even though
folded symbols have size zero, we cannot use the size-zero property in
lieu of `wasIdenticalCodeFolded`, because size zero symbols should still
get STABS entries.
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D136001
Symbols occur at non-zero offsets in a subsection if they are
`.alt_entry` symbols, or if `.subsections_via_symbols` is omitted.
It doesn't seem like ld64 supports folding those subsections either.
Moreover, supporting this it makes `foldIdentical` a lot more
complicated to implement. The existing implementation has some
questionable behavior around STABS omission -- if a section with an
non-zero offset symbol was folded into one without, we would omit the
STABS entry for the non-zero offset symbol.
I will be following up with a diff that makes `foldIdentical` zero out
the symbol sizes for folded symbols. Again, this is much easier to
implement if we don't have to worry about non-zero offsets.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D136000
A reference to __real_foo should trigger archive extraction of the input file that defines foo, otherwise a link using --wrap=foo might fail to link with an undefined reference to foo.
This matches bfd linker behaviour.
Differential Revision: https://reviews.llvm.org/D135897
Merge the checks done on the `c-string-literals` binary with those on
the main `test` binary. Also switch some checks to `-DAG` instead of
`-NEXT`. I'm about to extend this test, and this is easier to work with.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D135999
Define a `__heap_end` symbol that marks the end of the memory region
that starts at `__heap_base`. This will allow malloc implementations to
know how much memory they can use at `__heap_base` even if someone has
done a `memory.grow` before they can initialize their state.
Differential Revision: https://reviews.llvm.org/D136110
The target-specific code (AArch64, PPC64) does not fit into the generic code and
adds virtual function overhead. Move relocateAlloc into ELF/Arch/ instead. This
removes many virtual functions (relaxTls*). In addition, this helps get rid of
getRelocTargetVA dispatch and many RelExpr members in the future.
{D116279}, in addition to adding support for other demanglers, also
factored out some of the demangling logic. However, I don't think the
abstraction really carries its weight -- after {D135942}, only the ELF
and WASM backends call it with anything other than a non-constant
`shouldDemangle` argument. The COFF and Mach-O backends were already
doing the should-demangle check before calling `demangle()`.
Reviewed By: MaskRay, #lld-macho
Differential Revision: https://reviews.llvm.org/D135943
The only thing that the Common implementation does is a check for
`config->demangle`, but {D135189} added that check to
`maybeDemangleSymbol`, so there's no need to go through `Common`...
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135942
The previous form is currently "harmless" and happened to work but may not in the future:
Consider the struct: (for x86-64, but same issue can be said for the ARM/64 families):
```
UNWIND_X86_64_MODE_MASK = 0x0F000000,
UNWIND_X86_64_MODE_RBP_FRAME = 0x01000000,
UNWIND_X86_64_MODE_STACK_IMMD = 0x02000000,
UNWIND_X86_64_MODE_STACK_IND = 0x03000000,
UNWIND_X86_64_MODE_DWARF = 0x04000000,
```
Previously, we were doing: `(encoding & MODE_DWARF) == MODE_DWARF`
As soon as a new `UNWIND_X86_64_MODE_FOO = 0x05000000` is defined, then the check above would always return true for encoding=MODE_FOO (because `(0b0101 & 0b0100) == 0b0100` )
Differential Revision: https://reviews.llvm.org/D135359
This reverts commit 096f93e73dc3f88636cdcb57515e3732385b452d.
Revert "[Libomptarget] Make the plugins ingore undefined exported symbols"
This reverts commit 3f62314c235bd2475c8e2b5b874b2932a444e823.
Revert "[LLD] Enable --no-undefined-version by default."
This reverts commit 7ec8b0d162e354c703f5390784287054601f9c69.
Three commits are reverted because of the current omp build fail
with GNU ld. See discussion here: https://reviews.llvm.org/rG096f93e73dc3
We never noticed this before because the only time the size gets emitted is via
the linker map...
Reviewed By: #lld-macho, thakis
Differential Revision: https://reviews.llvm.org/D135884
This matches ld64's behavior.
Additionally, I edited the "Dead Stripped Symbols" header to omit "Address" --
this also matches ld64.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D135883
The llvm-driver, enabled with LLVM_TOOL_LLVM_DRIVER_BUILD combines many llvm executables
into one to save overall toolchain size. This patch adds the capability for lld to be part of the
llvm-driver.
Differential Revision: https://reviews.llvm.org/D127472
This flag acts just like the existing `--features` flag but instead
of replacing the set of inferred features it adds to it.
This is useful for example if you want to `--export` a mutable global
but none of the input of object were built with mutable global support.
In that case you can do `--extra-features=mutable-globals` to avoid the
linker error that would otherwise be generated in this case:
wasm-ld: error: mutable global exported but 'mutable-globals' feature not present in inputs: `__stack_pointer`. Use --no-check-features to suppress.
Differential Revision: https://reviews.llvm.org/D135831
While reading this code, I was wondering if we change these variables in the
loop. We don't, so make them const to make this easier to see next time.
No behavior change.
Differential Revision: https://reviews.llvm.org/D135877
The only difference in the reland is that the loop at the top of
getAlternativeSpelling() now calls dyn_cast_or_null() instead
of dyn_cast() -- a file's symbols list can contain null entries.
The test for this might be slightly involved, so I'll land it in
a follow-up, to make the reland similar to the original commit.
Originally reviewed at:
Differential Revision: https://reviews.llvm.org/D135038
This reverts commit 317b5582b813c51d1fb6723fd44b227b7f274bc7.
Allowing incorrect version scripts is not a helpful default. Flip that
to help users find their bugs at build time rather than at run time.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135402
We already do this for personality pointers referenced from compact
unwind entries; this patch extends that behavior to personalities
referenced via EH frames as well.
This reduces the number of distinct personalities we need in the final
binary, and helps us avoid hitting the "too many personalities" error.
I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare`
since we now do some non-reloc-specific stuff within.
Fixes#58277.
Reviewed By: #lld-macho, oontvoo
Differential Revision: https://reviews.llvm.org/D135728
This provides a workaround for a small difference in ld64 behavior where
ld64 ignores invalid LC_LINKER_OPTIONS unless the link fails. Instead of
fully adopting that behavior, this provides an escape hatch by allowing
users to specify `--ignore-auto-link-option` passing the invalid library
or framework name
Fixes https://github.com/llvm/llvm-project/issues/56939
Differential Revision: https://reviews.llvm.org/D135530
Previously unless ZERO_AR_DATE was set to any value, ld64.lld would
embed non-hermetic timestamps into the final binary. This flips that
default to zero those values unless ZERO_AR_DATE is set explicitly to 0.
As far as I know there isn't a downside to this, except that it differs
from ld64.
Differential Revision: https://reviews.llvm.org/D135529
Currently when the --thinlto-emit-index-files is used with LLD and a
thin archive is passed containing references to object files to link
against where the object files are in a different folder than the thin
archive and some of the archives aren't linked against (ie stay lazy),
the empty index file writer ends up trying to write to a path that
doesn't exist. This patch changes the behavior of that function to use
the path of the obj member of the BitcodeFile object rather than just
the path of the BitcodeFile object itself, which matches the behavior of
the default (non-lazy) case.
Fixes#57963
Regression test added.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D135014
This is a requirement from ld64, so this mirrors that expectation. Most
of these changes were just offsets from adding the library, or adding
dyld_stub_binder which is always added when linking ld64. This also adds
`%no-lsystem-lld` for the few cases where we're explicitly testing
things without that.
Fixes: https://github.com/llvm/llvm-project/issues/54184
Differential Revision: https://reviews.llvm.org/D135193
