Follow up to PR118508, to avoid unnecessary compile time for an empty
combind regular LTO module if all modules end up being ThinLTO only.
This required minor changes to a few tests to ensure they weren't empty.
According to the binutils spec:
https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html
You should be able to specify all files in an archive using this syntax
`archivename:` , however, lld currently will only accept `archivename:*`
to match all files within an archive.
This patch will, only when necessary, create a copy of the file
specification and add an implicit wildcard `*` to the end. It also
updates the filename-spec linkerscript test to check for this behavior.
---------
Co-authored-by: Peter Smith <peter.smith@arm.com>
This change ensures the load config in the hybrid image view is handled
correctly. It introduces a new Arm64XRelocVal class to abstract
relocation values, allowing them to be relative to a symbol. This class
will also be useful for managing ARM64X relocation offsets in the
future.
This change ensures that base relocations are sorted in the output,
aligning with MSVC linker behavior. While input files typically provide
sorted relocations, this update guarantees correct sorting even if the
input relocations are unordered.
This patch extends the MachO linker's map file generation to include
branch extension thunk symbols. Previously, thunks were omitted from the
map file, making it difficult to understand the final layout of the
binary, especially when debugging issues related to long branch thunks.
This change ensures thunks are included and correctly interleaved with
other symbols based on their address, providing an accurate
representation of the linked output.
Port https://reviews.llvm.org/D117354 from the MachO port.
If both --symbol-ordering-file and call graph profile are present, the
--symbol-ordering-file takes precedence, but the call graph profile is
still used for symbols that don't appear in the order file.
In addition, call graph profile described sections are now ordered
before other sections.
cg_profile in object is from CGProfilePass and it is often inaccurate.
While call-graph-ordering-file is provided by user. It is weird to
aggregate them together especially when call-graph-ordering-file is
accurate enough.
This already worked without /wholearchive; now it works with it too.
(Only for thin archives containing relative file names, matching the ELF
and Mach-O ports.)
The commit 22b7b84860d39da71964c9b329937f2ee1d875ba
made the symbols provided by shared libraries "defined",
and thus effectively made it impossible to generate non-pie
dynamically linked executables using
--unresolved-symbols=import-dynamic.
This commit, based on https://github.com/llvm/llvm-project/pull/109249,
fixes it by checking sym->isShared() explictly.
(as a bonus, you don't need to rely on
--unresolved-symbols=import-dynamic
anymore.)
Fixes https://github.com/llvm/llvm-project/issues/107387
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
