This can be used with /llvmlibthin to create thin archives without an
index, which is a prerequisite for porting
https://reviews.llvm.org/D117284 to lld-link.
Creating files like this is already possible with `llvm-ar rcS`, so this
doesn't add additional problems.
That change forgot to set `lazy` to false before calling `addFile()` in
`forceLazy()` which caused `addFile()` to parse the file we want to
force a load for to be added as a lazy object again instead of adding
the file to `ctx.objFileInstances`.
This is caught by a pretty simple test (included).
If foo.obj is eagerly loaded (due to a prior undef referencing one if
its symbols) and has more than one symbol, we used to assert:
SymbolTable::addLazyObject() for the first symbol would set `lazy` to
false and load all symbols from the file, but the outer
ObjFile::parseLazy() loop would continue to run and call addLazyObject()
for the second symbol, which would assert.
Instead, just stop adding lazy symbols if the file got loaded for real
while adding a symbol.
(The ELF port has a similar early exit in `ObjFile<ELFT>::parseLazy()`.)
Depends on #114525
Support `R_AARCH64_AUTH_GOT_ADR_PREL_LO21` and `R_AARCH64_AUTH_GOT_LD_PREL19`
GOT-generating relocations. A corresponding `RE_AARCH64_AUTH_GOT_PC` member
of `RelExpr` is added, which is an AUTH-specific variant of `R_GOT_PC`.
Previously, we'd collect all input files in Driver::filePaths, and then
write filePaths after all other flags in
createResponseFile(). This meant that `-start-lib foo.obj -end-lib`
would be written as `-start-lib -end-lib foo.obj`, changing semantics.
Instead, remove Driver::filePaths, and handle things that fed into it
directly:
* OPT_INPUT is now handled in the same way as other flags, so that we
now get `-start-lib foo.obj -end-lib` in response.txt as desired. Add a
test for -start-lib / -end-lib and /reproduce:.
* OPT_wholearchive_file needs explicit handling now -- but before, this
was buggy as well: We'd put the flag without a rewritten path in
response.txt, but also the rewritten input file without wholearchive
semantics via filePaths. So this commit makes --whole-archive work with
/reproduce: too, and adds test coverage.
* /defaultlib:foo is now written as /defaultlib:foo into response.txt,
instead of writing the resolved path previously. While response.txt
looks slightly differently, both should have the same semantics, and
this should be mostly a no-op. (It does require updating a test.)
* /defaultlib: from .drectve sections are no longer recorded in
response.txt. This seems like a progression -- in the non-repro case
they come from .obj files, so they should come (only) from there in the
repro case too. This adds test coverage for this case.
Makes createResponseFile() look more like the versions in the ELF and
MachO ports too.
Depends on #113811
Support `R_AARCH64_AUTH_ADR_GOT_PAGE`, `R_AARCH64_AUTH_GOT_LO12_NC` and
`R_AARCH64_AUTH_GOT_ADD_LO12_NC` GOT-generating relocations. For preemptible
symbols, dynamic relocation `R_AARCH64_AUTH_GLOB_DAT` is emitted. Otherwise,
we unconditionally emit `R_AARCH64_AUTH_RELATIVE` dynamic relocation since
pointers in signed GOT needs to be signed during dynamic link time.
On hybrid ARM64X targets, ARM64 and ARM64EC input files operate in
separate namespaces and cannot reference each other. This change
introduces separate `SymbolTable` instances and associates each
`InputFile` with the appropriate table to reflect this behavior.
1. Fix the offset for R_X86_64_CODE_6_GOTTPOFF fixup, which is
introduced by #117277. It should be biased with the size of the
immediate field. Related tests are updated.
2. Rename reloc_riprel_6byte_relax to reloc_riprel_4byte_relax_evex as
the number of bytes represents the size of fixup, and "evex" suffix is added
as it's used for APX NDD/NF instructions with EVEX prefix.
3. Remove incorrectly setting R_X86_64_CODE_6_GOTTPOFF relocation type
for APX NDD/NF instructions with GOTPCREL symbol reference modifier.
A linkonce_odr definition can be omitted in LTO compilation if
`canBeOmittedFromSymbolTable()` is true in all bitcode files.
Currently, we don't respect the `canBeOmittedFromSymbolTable()` bit from
symbols in a non-prevailing COMDAT, which could lead to incorrect
omission of a definition when merging a prevailing linkonce_odr and a
non-prevailing weak_odr, e.g. an implicit template instantiation and an
explicit template instantiation.
To fix#111341, allow the non-prevailing COMDAT code path to clear the
`ltoCanOmit` bit, so that `VisibleToRegularObj` could be false in
LTO.cpp. We could resolve either an Undefined or a Defined. For
simplicity, just use a Defined like the prevailing case (similar to how
we resolve symbols in ObjectFile COMDAT reviews.llvm.org/D120626).
Pull Request: https://github.com/llvm/llvm-project/pull/119332
Section merging can increase section alignment after potential spill
sections are created. Since this operation is never performed on spill
sections, they can keep their earlier, smaller, alignment, which
produces a misalignment if a spill occurs.
This change propagates alignment increases forward after merging.
A linkonce_odr definition can be omitted in LTO compilation if
`canBeOmittedFromSymbolTable()` is true in all bitcode files.
Test more linkage merge scenarios.
The lo_and_wo symbol tests #111341.
Test linker-synthesized symbols in addReservedSymbols and in
finalizeSections. `isExported` is set in the middle.
The hidden symbol test could have caught an assertion failure introduced
by 712264b83c736fac7a7f0d4296f84c1afbd93b1a and fixed by
3733ed6f1c6b0eef1e13e175ac81ad309fc0b080.
Thumb short thunks use the B.w instruction. This instruction is not
present on Arm v6-m so we should prevent these targets from using
short-thunks. We want to permit Arm v8-m.base targets to continue using
short thunks as it does have the B.w instruction despite not
implementing all of Thumb 2.
Add a check to see if the Movt and Movw instructions are present before
enabling short thunks for Thumb. The v6-m architecture has
J1J2BranchEncoding, but it does not have Movt and Movw, whereas
v8-m.base has both.
The memory map and limited flash size of an Arm v6-m CPU makes a short
thunk very unlikely in practice, but it is worth getting it right just
in case.
This reverts commit 2b129dacdde667137b5012d52f1d96e0ab26c749.
parseSymbolVersion can be combined with computeIsPreemptible,
making hasVersionSyms unneeded.
We can just scan objectFiles and sharedFiles that have versioned symbols
to skip scanning the global symtab. While we won't suggest __wrap_foo
for undefined __wrap_foo@v1 when --wrap=foo@v1 is specified
(internalFile isn't scanned), this edge case difference is acceptable.
Implement MSVC's `/DEPENDENTLOADFLAG` as `--dependent-load-flag` and
forward it to COFF.
ld.bfd doesn't support it, yet at least, but if they later add support for something similar, hopefully they’d agree to the same option name.
There is no solid need for it yet, but it's being considered:
https://github.com/msys2/MINGW-packages/pull/22216#issuecomment-2428417546
When both `-order_file` and `--irpgo-profile-sort=` (soon to be
`-bp-startup-sort=function` in
https://github.com/llvm/llvm-project/pull/118594) are used, we want to
confirm that symbols in the orderfile take precedence.
This modifies the machine field in the hybrid view to be AMD64, aligning
it with expectations from ARM64EC modules. While this provides initial
support, additional relocations will be necessary for full
functionality. Many of these cases depend on implementing separate
namespace support first.
Move clearing of the .reloc section from addBaserels to assignAddresses
to ensure it is always cleared, regardless of the relocatable
configuration. This change also clarifies the reasoning for adding the
dynamic relocations chunk in that location.
In #86751 we moved the IRELATIVE relocations to .rela.plt when
--pack-dyn-relocs=android was enabled but we neglected to also move
the __rela_iplt_{start,end} symbols. As a result, static binaries
linked with this flag were unable to find their IRELATIVE relocations.
Fix it by having the symbols surround the correct section.
Reviewers: MaskRay, smithp35
Reviewed By: MaskRay
Pull Request: https://github.com/llvm/llvm-project/pull/118585
This defines some new target features. These are subsets of existing
features that reflect implementation concerns:
- "call-indirect-overlong" - implied by "reference-types"; just the
overlong encoding for the `call_indirect` immediate, and not the actual
reference types.
- "bulk-memory-opt" - implied by "bulk-memory": just `memory.copy` and
`memory.fill`, and not the other instructions in the bulk-memory
proposal.
This is split out from https://github.com/llvm/llvm-project/pull/112035.
---------
Co-authored-by: Heejin Ahn <aheejin@gmail.com>
The R_ARM_SBREL32 relocation is used in debug info for ARM RWPI
(read-write position independent) code. Compiler-generated DWARF info
will use an expression to add the relocated value to the actual value of
the static base (held in r9) at run-time, so it should be relocated as
if the static base is at address 0.
Inferring the ARM64EC target can lead to errors. The `-machine:arm64ec`
option may include x86_64 input files, and any valid ARM64EC input is
also valid for `-machine:arm64x`. MSVC requires an explicit `-machine`
argument with informative diagnostics; this patch adopts the same
behavior.
Follow-up to the NFC refactoring
43e3871a327b8e2ff57e16b46d5bc44beb430d91 and test cleanup
3cecf17065919da0a7fa9b38f37592e5462c2f85.
SHF_MERGE sections with relocations are handled as InputSection (without
duplicate elimination). The output section retains the original
sh_entsize in non-relocatable links. This patch ports the behavior for
relocatable links as well.
https://github.com/ClangBuiltLinux/linux/issues/2057
Add new CLI options for feature parity with ELF w.r.t pass plugins.
Most of the changes are ported directly from
0c86198b27.
With this change, it is now possible to load and run external pass
plugins during the LTO phase.
When we create a thunk we don't know whether it will be short or long.
Move the emission of the long thunk mapping symbol to when we transition
to a long thunk. This improves disassembly and binary analysis as tools
like BOLT identify thunks by disassembly.
This removes a FIXME added in #108989 aarch64-thunk-bti-multipass.s
which had a corrupt disassembly due to missing mapping symbols.
ld64.lld would previously allow you to link against dylibs linked with
`-allowable_client`, even if the client's name does not match any
allowed client.
This change fixes that. See #114146 for related discussion.
The test binary `liballowable_client.dylib` was created on macOS with:
echo | clang -xc - -dynamiclib -mmacosx-version-min=10.11 -arch x86_64
-Wl,-allowable_client,allowed -o lib/liballowable_client.dylib
Currently when `--icf=safe_thunks` is used, `STABS` entries cannot be
generated for ICF'ed functions. This is because if ICF converts a full
function into a thunk and then we generate a `STABS` entry for the
thunk, `dsymutil` will expect to find the entire function body at the
location of the thunk. Because just a thunk will be present at the
location of the `STABS` entry - dsymutil will generate invalid debug
info for such scenarios.
With this change, if `--icf=safe_thunks` is used and `--keep-icf-stabs`
is also specified, STABS entries will be created for all functions, even
merged ones. However, the STABS entries will point at the actual (full)
function body while having the name of the thunk. This way we still get
program correctness as well as correct DWARF data. When doing this, the
debug data will be identical to the scenario where we're using
`--icf=all` and `--keep-icf-stabs`, but the actual program will also
contain thunks, which won't show up in the DWARF data.
Rename R_X86_64_REX2_GOTPCRELX to R_X86_64_CODE_4_GOTPCRELX, to align
with GCC/binutils and ABI.
GCC/binutils:
3d5a60de52
and
4a54cb0658
ABI:
357de358ba
