Age | Commit message (Collapse) | Author |
|
|
|
This is feature of the ELF and COFF linker that we were missing until
now.
Differential Revision: https://reviews.llvm.org/D137377
|
|
Also simplify code for liblldCommon using the new LLVM_ATOMIC_LIB variable.
Depends on D136280.
Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136281
|
|
Accompanying https://reviews.llvm.org/D125728, this updates LLVM
Codegen's "generic" CPU to enable the same new features.
Differential Revision: https://reviews.llvm.org/D125729
|
|
|
|
arbitrary names
This adds an `--export-memory` option to wasm-ld which allows passing
a name to give to the exported memory, and extends `--import-memory` to
allow passing a <module>,<name> pair specifying where the memory should
be imported from.
This is based on https://reviews.llvm.org/D131376, with the main
difference being that it only supports exporting memory by one name.
Differential Revision: https://reviews.llvm.org/D135898
|
|
This patch fixes:
lld/MachO/SyntheticSections.cpp: In member function ‘virtual void
lld::macho::ChainedFixupsSection::writeTo(uint8_t*) const’:
|
|
This patch fixes:
lld/MachO/OutputSegment.cpp:50:43: warning: enumerated and
non-enumerated type in conditional expression [-Wextra]
|
|
This prepares for an upcoming change to make --print-imm-hex the default
behavior of llvm-objdump. These tests were updated in a semi-automatic
fashion.
See D136972 for details.
|
|
These need to have special treatment wrt to .eh_frame sections
and GC - as long as we don't have a full parser of the .eh_frame
section in the COFF linker.
This fixes Rust unwind issues on i686 mingw as discussed in
https://github.com/msys2/MINGW-packages/issues/9091.
Differential Revision: https://reviews.llvm.org/D136879
|
|
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
|
|
This reverts commit 88d7508dc479210f07abccb17f0194b66264b125.
It's reported to break builds when symlinking other projects inside
the `tools` directory.
|
|
Move `cmake_policy()` settings from `llvm/CMakeLists.txt` into a shared
`cmake/modules/CMakePolicy.cmake`. Include it from all relevant
projects that support standalone builds, in order to ensure that
the policies are consistently set whether they are built in-tree
or stand-alone.
Differential Revision: https://reviews.llvm.org/D136572
|
|
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
|
|
Following up on D125729, add -mcpu-mvp to wasm-ld tests that use llc to
avoid test changes as a result of default target changes.
|
|
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
|
|
Include symbol sizes (present after {D135883}) as well as an example of
a dead-stripped symbol.
|
|
in different COMDATs
```
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
|
|
- remove unused/duplicate includes
- reformatting/whitespaces
Differential Revision: https://reviews.llvm.org/D136266
|
|
-share/-pie or --relocatable modes
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
|
|
relocateAlloc may be parallel so we should avoid sharing AArch64 states.
|
|
for foo
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.
|
|
Prepare for a refactoring.
|
|
|
|
|
|
|
|
|
|
|
|
{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
|
|
mode-mask checking logic for clarity
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
|
|
Differential Revision: https://reviews.llvm.org/D135879
|
|
Currently emscripten is make assumptions about that memory layout,
assuming the stack is between `__data_end` and `__heap_base`:
https://github.com/emscripten-core/emscripten/blob/af961ad5c4c278ec510f0b7f7d522a95ee5a90f8/system/lib/compiler-rt/stack_limits.S#L42-L61
With this change we can be more precise:
https://github.com/emscripten-core/emscripten/pull/18057
Differential Revision: https://reviews.llvm.org/D135910
|
|
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
|
|
Differential Revision: https://reviews.llvm.org/D135889
|
|
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
|