| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This patch renames {starts,ends}with to {starts,ends}_with for
consistency with std::{string,string_view}::{starts,ends}_with in
C++20. Since there are only a handful of occurrences, this patch
skips the deprecation phase and simply renames them.
|
|
Add tests for COV4 as well as COV5 instead of only testing for the
default version.
|
|
relocateNonAlloc is costly for .debug_* section relocating. We don't
want to burn CPU cycles on other targets' workarounds.
Remove a temporary workaround for Linux objtool after a proper fix
https://git.kernel.org/linus/b8ec60e1186cdcfce41e7db4c827cb107e459002
Move the R_386_GOTPC workaround for GCC<8 beside the R_PC workaround.
|
|
|
|
Add 32-bit test for -z dead-reloc-in-nonalloc= and add tests for a
non-x86 64-bit (x86-64 is unique in discerning signed/unsigned 32-bit
absolute relocations (R_X86_64_32/R_X86_64_32S).
AArch64/PPC64/RISC-V/etc don't have the distinction). Having a test will
improve coverage for #74686
|
|
|
|
[RFC](https://discourse.llvm.org/t/rfc-add-build-id-flag-to-lld-link/74661)
Before, lld-link only generate the debug directory containing guid when
generating PDB with the hash of PDB content.
With this change, lld-link can generate the debug directory when only
`/build-id` is given:
1. If generating PDB, `/build-id` is ignored. Same behaviour as before.
2. Not generating PDB, using hash of the binary.
- Not under MinGW, the debug directory is still in `.rdata` section.
- Under MinGW, place the debug directory into new `.buildid` section.
|
|
ARM64EC needs to handle both ARM and x86_64 exception tables. This is
achieved by separating their chunks and sorting them separately.
EXCEPTION_TABLE directory references x86_64 variant, while ARM variant
is exposed using CHPE metadata, which references
__arm64x_extra_rfe_table and __arm64x_extra_rfe_table_size symbols.
|
|
This redoes the fix from 3ab6209a3f93bdbeec8e9b9fcc00a9a4980915ff
differently, without the unwanted effect of preserving unnecessary
`__imp_` prefixed symbols.
If the referencing object is a regular object, the `__imp_` symbol will
have `isUsedInRegularObj` set on it from that already. If the
referencing object is an LTO object, we set `isUsedInRegularObj` for any
symbol starting with `__imp_`.
If the object file defining the `__imp_` symbol is a regular object, the
`isUsedInRegularObj` flag has no effect. If it is an LTO object, it
causes the symbol to be preserved.
|
|
|
|
(#73977)
This fixes a mis-link when mixing compressed and non-compressed input to
LLD. When relaxing calls, we must respect the source file that the
section came from when deciding whether it's legal to use compressed
instructions. If the call in question comes from a non-rvc source, then it will not
expect 2-byte alignments and cascading failures may result.
This fixes https://github.com/llvm/llvm-project/issues/63964. The symptom
seen there is that a latter RISCV_ALIGN can't be satisfied and we either
fail an assert or produce a totally bogus link result. (It can be easily
reproduced by putting .p2align 5 right before the nop in the reduced
test case and running check-lld on an assertions enabled build.) However,
it's important to note this is just one possible symptom of the problem.
If the resulting binary has a runtime switch between rvc and non-rvc
routines (via e.g. ifuncs), then even if we manage to link we may execute invalid
instructions on a machine which doesn't implement compressed instructions.
|
|
Dead store elimination pass may fold malloc + memset calls into a single
call to calloc. If calloc is not preserved and is not being called
it can be marked dead which results in link error.
|
|
|
|
This change removes an unnecessary branch from a hot path. It's also
questionable API to override any previous error unconditonally.
|
|
This reverts commit 545c8e009e2b649ef38f7e432ffbc06ba8a9b813.
|
|
This change removes an unnecessary branch from a hot path. It's also
questionable API to override any previous error unconditonally.
|
|
calloc) libcall optimization
Similar to https://reviews.llvm.org/D50017: malloc+memset references can
be combined to a calloc reference, which is not explicit in the
referencer's IR symbol table. If calloc is defined in a lazy bitcode
file, we should extract the archive member to satisfy possible
references from LTO generated object files; otherwise (current status,
which will be fixed by #72673), `calloc` as a LazyObject symbol will be
resolved by compileBitcodeFiles generated Undefined, leading to an
incorrectly-extracted Defined symbol without section, which will lower
to an SHN_ABS symbol at address 0.
|
|
When doing LTO on multiple archives, the order with which bitcodes are
linked to the LTO module is hard to control, given that processing
undefined symbols can lead to parsing of an object file, which in turn
lead to parsing of another object file before finishing parsing of the
previous file. This can result in encountering a non-prevailing comdat
first when linking, which can make the the symbol undefined, and the
real definition is added later with an additional prefix to avoid
duplication (e.g. `__cxx_global_var_init` and `__cxx_global_var_init.2`)
So this one-line fix ensures we compile bitcodes in the order that we
process comdats, so that when multiple archived bitcode files have the
same variable with the same comdat, we make sure that the prevailing
comdat will be linked first in the LTO.
Fixes #62243.
|
|
Similar to e752b58e0d26.
|
|
Test that getBitcodeMachineKind can get right e_machine for
Triple::loongarch64 and Triple::loongarch32 during LTO.
|
|
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
Now restricted to platforms that support .subsections_via_symbols.
This reverts commit 797b68c0ba699994e1038ac33d3083541482bf19.
Fixes: #72802
Differential revision: https://reviews.llvm.org/D153167
rdar://111459507
|
|
sections (#72610)
For a label difference like `.uleb128 A-B`, MC generates a pair of
R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128 if A-B cannot be folded as a
constant. GNU assembler generates a pair of relocations in more cases
(when A or B is in a code section with linker relaxation).
`.uleb128 A-B` is primarily used by DWARF v5
.debug_loclists/.debug_rnglists (DW_LLE_offset_pair/DW_RLE_offset_pair
entry kinds) implemented in Clang and GCC.
`.uleb128 A-B` can be used in SHF_ALLOC sections as well (e.g.
`.gcc_except_table`). This patch does not handle SHF_ALLOC.
`-z dead-reloc-in-nonalloc=` can be used to change the relocated value,
if the R_RISCV_SET_ULEB128 symbol is in a discarded section. We don't
check the R_RISCV_SUB_ULEB128 symbol since for the expected cases A and
B should be defined in the same input section.
|
|
Commit b963c0b658cc54b370832df4f5a3d63fd69da334 fixed LTO compilation of
cases where one translation unit is calling a function with the
dllimport attribute, and another translation unit provides this function
locally within the same linked module (i.e. not actually dllimported);
see https://github.com/llvm/llvm-project/issues/37453 or
https://bugs.llvm.org/show_bug.cgi?id=38105 for full context.
This was fixed by aliasing their GlobalResolution structs, for the
`__imp_` prefixed and non prefixed symbols.
I believe this fix to be wrong.
This patch reverts that fix, and fixes the same issue differently,
within LLD instead.
The fix assumed that one can treat the `__imp_` prefixed and unprefixed
symbols as equal, referencing SVN r240620
(d766653534e0cff702e42a43b44d3057b6094fea). However that referenced
commit had mistaken how this logic works, which was corrected later in
SVN r240622 (88e0f9206b4dccb56dee931adab08f89ff80525a); those symbols
aren't direct aliases for each other - but if there's a need for the
`__imp_` prefixed one and the other one exists, the `__imp_` prefixed
one is created, as a pointer to the other one.
However this fix only works if both translation units are compiled as
LTO; if the caller is compiled as a regular object file and the callee
is compiled as LTO, the fix fails, as the LTO compilation doesn't know
that the unprefixed symbol is needed.
The only level that knows of the potential relationship between the
`__imp_` prefixed and unprefixed symbol, across regular and bitcode
object files, is LLD itself.
Therefore, revert the original fix from
b963c0b658cc54b370832df4f5a3d63fd69da334, and fix the issue differently
- when concluding that we can fulfill an undefined symbol starting with
`__imp_`, mark the corresponding non prefixed symbol as used in a
regular object for the LTO compilation, to make sure that this non
prefixed symbol exists after the LTO compilation, to let LLD do the
fixup of the local import.
Extend the testcase to test a regular object file calling an LTO object
file, which previously failed.
This change also fixes another issue; an object file can provide both
unprefixed and prefixed versions of the same symbol, like this:
void importedFunc(void) {
}
void (*__imp_importedFunc)(void) = importedFunc;
That allows the function to be called both with and without dllimport
markings. (The concept of automatically resolving a reference to
`__imp_func` to a locally defined `func` only is done in MSVC style
linkers, but not in GNU ld, therefore MinGW mode code often uses this
construct.)
Previously, the aliasing of global resolutions at the LTO level would
trigger a failed assert with "Multiple prevailing defs are not allowed"
for this case, as both `importedFunc` and `__imp_importedFunc` could be
prevailing. Add a case to the existing LLD test case lto-imp-prefix.ll
to test this as well.
This change (together with previous change in
3ab6209a3f93bdbeec8e9b9fcc00a9a4980915ff) completes LLD to work with
mingw-w64-crt files (the base glue code for a mingw-w64 toolchain) built
with LTO.
|
|
NFC. (#72764)
The commit 3ab6209a3f93bdbeec8e9b9fcc00a9a4980915ff had the undesired
effect of retaining every `__imp_` symbol, even if it isn't referenced
in any way. Add a testcase to observe this behaviour, to serve as
a reference point if this behaviour were to be improved later.
Port the testcase from b963c0b658cc54b370832df4f5a3d63fd69da334 from
the llvm/LTO testsuite into LLD as a preparation for changing that fix;
the moved testcase has a comment for one case which doesn't work
currently.
The testcase is ported mostly as is, but with symbol mangling
simplified, rewriting function names from MSVC C++ mangling to plain
C, and unnecessary debug info is removed.
Add a case of a dllimported data symbol, in addition to the existing
call of a dllimported function.
Also extend the testcase to test combinations of both regular
object files and LTO objects. Leave out one combination which currently
fails, with a comment.
|
|
Add armeb support when incoming bc is arm big endian:
Fix error: could not infer e_machine from bitcode target triple
armebv7-linux-gnueabi.
|
|
This reverts commit 4323da926f12672daec7f59384bd153a7cf28674.
This broke building libffi for ARM on Windows (and probably Darwin),
where one extern function intentionally falls through to another
one, while sharing one CFI region.
As long as one isn't using .subsections_via_symbols on MachO,
this probably shouldn't be a hard error.
Secondly, the tested pattern only produces an error on MachO and
COFF targets, but not for ELF, making the error case even more
inconsistent.
Reverting this commit for now, to figure out the best way forward.
|
|
placed in an output section
This ports https://reviews.llvm.org/D40652 (--emit-relocs) to -r and
matches GNU ld.
Close #67910
|
|
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
rdar://111459507
Differential revision: https://reviews.llvm.org/D155245
This reverts commit 4172fcc1ebbe0a7b699bfcbdaae9d5f688b62b09.
|
|
This reverts commit 2fd343e56c9fe3cdb1f9afe0fc9e1ec6d52d2f44.
Breaks building aarch64 builtins, see https://reviews.llvm.org/D155245.
|
|
|
|
This showed up when simplifying some large testcase, where the cfi directives
became out of sync with the proc's they enclose.
rdar://111459507
Differential revision: https://reviews.llvm.org/D155245
This reverts commit 4172fcc1ebbe0a7b699bfcbdaae9d5f688b62b09.
|
|
This is a preparation for ARM64EC support, which needs to sort both ARM
and x86_64 tables separately.
|
|
|
|
|
|
The two fields are similar.
`versionId` is the Verdef index in the output file. It is set for
`--exclude-id=`, version script patterns, and `sym@ver` symbols.
`verdefIndex` is the Verdef index of a Sharedfile (SharedSymbol or a
copy-relocated Defined), the default value -1 is also used to indicate
that the symbol has not been matched by a version script pattern
(https://reviews.llvm.org/D65716).
It seems confusing to have two fields. Merge them so that we can
allocate one bit for #70130 (suppress --no-allow-shlib-undefined
error in the presence of a DSO definition).
|
|
The new RUN line `ld.lld --version-script=a.ver b.so a.o -o a1`
`c3` would be able to caught `replaceWithDefined` bug in
commit 667ea2ca408bbfb29f6d138b6c758542e329b2c5 (#72208).
|
|
Reverts llvm/llvm-project#72208
If a unversioned Defined preempts a versioned DSO definition, the
version ID will not be reset.
|
|
|
|
The R_LARCH_{ADD,SUB}6 relocation type are usually used by DwarfCFA to
calculate a tiny offset. They appear after binutils 2.41, with GAS
enabling relaxation by default.
|
|
data section. (#72030)
|
|
Filling entire buffer would require all chunks to overwrite it later,
which is not the case for uninitialized chunks merged into code
sections.
|
|
The two fields are similar.
`versionId` is the Verdef index in the output file. It is set for
version script patterns and `sym@ver` symbols.
`verdefIndex` is the Verdef index of a SharedSymbol. The default value
-1 is also used to indicate that the symbol has not been matched by a
version script pattern (https://reviews.llvm.org/D65716).
It seems confusing to have two fields. Merge them so that we can
allocate one bit for #70130 (suppress --no-allow-shlib-undefined
error in the presence of a DSO definition).
|
|
|
|
|
|
If `page(dest) - page(pc)` is 0xfffffffffff000, i.e. page(pc) is next
to page(dest), and lo12(dest) > 0x7ff, correct %pc64_lo12 and %pc64_hi12
should be both -1 (which can be checked with binutils) but they are both
0 on lld. This patch adds such a test showing lld's incorrect behaviour
and following patch will fix this issue.
|
|
This fixes: https://lab.llvm.org/buildbot/#/builders/65/builds/11819
Also see discussion in: https://github.com/llvm/llvm-project/pull/71537
|
|
When forming MachO STABS, this change detects if the DW_AT_name of the
compile unit is already absolute (as allowed by DWARF), and if so, does
not prepend DW_AT_comp_dir.
Fixes #70995
|
|
It seems that some functions (.text.unlikely.xxx) may have zero size,
which
makes some builds with enabled assertions fail. Removing the assertion
and
extending one test to fix the build.
The sorting can process such zero-sized functions so no changes there
are needed
|
|
This should fix https://github.com/llvm/llvm-project/issues/43935
|
|
Accidentally deleted it in a previous commit.
|
