The reverted
1a4d6de1b532149b10522eae5dabce39e5f7c687
("[ELF] Remove redundant isExported computation")
had incorrect
```
+ if (sym->includeInDynsym(ctx))
+ sym->isExported = true;
```
causing undefined weak symbols (defined in archives, demoted; e.g.
__cxa_finalize) to be exported for static-pie.
Add a regression test for this corner case. The issue actually exposed
another issue related to includeInDynsym, which has been fixed by
f10441ad003236ef3b9e5415a571d2be0c0ce5ce.
`includeInDynsym` has a special case for isUndefWeak and
--no-dynamic-linker, which can be removed if we simplify disallow
dynamic symbols for static-pie.
The partition feature reports errors only when a symbol `isExported`.
We need to link in a DSO to trigger the mips error.
This mode does not retain definitions in GNU ld. While we do, it's not
consistent with the decision that there is no .dynsym . We will change
this and simplify some internal representations.
This enables the LLD_IN_TEST=2 testing mode for
```
path/to/llvm-lit -sv --param RUN_LLD_MAIN_TWICE=1 lld/test/ELF
```
When `Fatal` is called, `RunSafely` will return false.
For the first invocation in LLD_IN_TEST=2 mode, `inTestOutputDisabled`
is true and lld will not write to stdout/stderr, making many tests fail.
(This essentially discourages `Fatal` calls in the source code.)
Add XFAIL: main-run-twice to these tests similar to
https://reviews.llvm.org/D112898 for Mach-O
```
comment="This test intentionally checks for fatal errors, and fatal errors aren't supported for testing when main is run twice."
xargs </tmp/0 sed -Ei "1s/(;|#|\/\/) REQUIRES: .*/\0\n\1 "$comment"\n\1 XFAIL: main-run-twice/;t;1s/^/# "$comment"\n# XFAIL: main-run-twice\n/"
```
This reverts commit 048f35037779763963c4b4478a0884e828ea9538.
This reverts commit f7bbc40b0736cc417f57cd039b098b504cf6a71f.
Related to #95949. A developer with no prior lld contribution and very
little AMD contribution sneaked in these application-specific section
order rules we discourage.
In hybrid images, the PE header references a single IAT for both native
and EC views, merging entries where possible. When merging isn't
feasible, different imports are grouped together, and ARM64X relocations
are emitted as needed.
In LLD_IN_TEST=2 mode, when a thread calls Fatal, there will be no
output even if the process exits with code 1. Change the Fatal to
ErrAlways (not-recoverable) as subsequent code assumes SHF_LINK_ORDER
sh_link is correct.
In LLD_IN_TEST=2 mode, when a thread calls Fatal, there will be no
output even if the process exits with code 1. Change a few Fatal to
recoverable Err.
In LLD_IN_TEST=2 mode, when a thread calls Fatal, there will be no
output even if the process exits with code 1. Change a few Fatal to
recoverable Err.
In LLD_IN_TEST=2 mode, when a thread calls Fatal, there will be no
output even if the process exits with code 1. Change a few Fatal to
recoverable Err.
These diagnostics are mostly reported by a thread during writeSections.
In LLD_IN_TEST=2 mode, when a thread calls Fatal, there will be no
output even if the process exits with code 1.
`NullChunk` instances do write data, even if it's always zero. Setting
`hasData` to false causes `Writer::assignAddresses` to ignore them
when calculating `rawSize`. This typically isn't an issue, as null chunks
are usually positioned within a section, and later chunks adjust the
size accordingly.
However, on ARM64EC, the auxiliary IAT is placed at the end of the
`.rdata` section and terminates with a null chunk. As a result, `rawSize`
is never updated to account for it, and space for the null chunk is not
allocated. Consequently, when `NullChunk::writeTo` is called, it receives
an invalid pointer - either pointing to the next section or beyond the
allocated buffer.
This is a follow-up to #120452 in a way.
Since lld/COFF does not yet insert all defined in an obj file before all
undefineds (ELF and MachO do this, see #67445 and things linked from
there), it's possible that:
1. We add an obj file a.obj
2. a.obj contains an undefined that's in b.obj, causing b.obj to be
added
3. b.obj contains an undefined that's in a part of a.obj that's not yet
in the symbol table, causing a recursive load of a.obj, which adds the
symbols in there twice, leading to duplicate symbol errors.
For normal archives, `ArchiveFile::addMember()` has a `seen` check to
prevent this. For start-lib lazy objects, we can just check if the
archive is still lazy at the recursive call.
This bug is similar to issue #59162.
(Eventually, we'll probably want to do what the MachO and ELF ports do.)
Includes a test that caused duplicate symbol diagnostics before this
code change.
The symbol string table does not have deduplication.
Here we add code to deduplicate the symbol string table.
This has a rather large size impact (20-30%) on unstripped binaries
(typically debug binaries) but no size impact on stripped
binaries(typically release binaries).
We enable deduplication by default and add a flag to disable it
(`-no-deduplicate-symbol-strings`).
.note.GNU-stack with the SHF_EXECINSTR flag requires an executable
stack. This is exceedingly rare. We report an error to force
the user to explicitly request an executable stack.
Close#121234
Pull Request: https://github.com/llvm/llvm-project/pull/124068
ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b tried to fix cases when LLD
links what seems to be import library header objects from MSVC. However,
the fix seems incorrect; the review at https://reviews.llvm.org/D133627
concluded that if this (treating this kind of symbol as a common symbol)
is what link.exe does, it's fine.
However, this is most probably not what link.exe does. The symbol
mentioned in the commit message of
ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b would be a common symbol with a
size of around 3 GB; this is not what might have been intended.
That commit tried to avoid running into the error ".idata$4 should not
refer to special section 0"; that issue is fixed for a similar style of
section symbols in 4a4a8a1476b1386b523dc5b292ba9a5a6748a9cf.
Therefore, revert ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b and extend
the fix from 4a4a8a1476b1386b523dc5b292ba9a5a6748a9cf to also work for
the section symbols in MSVC generated import libraries.
The main detail about them, is that for symbols of type
IMAGE_SYM_CLASS_SECTION, the Value field is not an offset, but it is an
optional set of flags, corresponding to the Characteristics of the
section header (although it may be empty).
This is a reland of a previous version of this commit, earlier merged in
9457418e66766d8fafc81f85eb8045986220ca3e / #122811. The previous version
failed tests when run with address sanitizer. The issue was that the
synthesized coff_symbol_generic object actually will be used to access a
full coff_symbol16 or coff_symbol32 struct, see
DefinedCOFF::getCOFFSymbol. Therefore, we need to make a copy of the
full size of either of them.
Depends on #120010
Support `R_AARCH64_AUTH_TLSDESC_ADR_PAGE21`, `R_AARCH64_AUTH_TLSDESC_LD64_LO12`
and `R_AARCH64_AUTH_TLSDESC_LD64_LO12` static relocations and
`R_AARCH64_AUTH_TLSDESC` dynamic relocation. IE/LE optimization is not
currently supported for AUTH TLSDESC.
ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b tried to fix cases when LLD
links what seems to be import library header objects from MSVC. However,
the fix seems incorrect; the review at https://reviews.llvm.org/D133627
concluded that if this (treating this kind of symbol as a common symbol)
is what link.exe does, it's fine.
However, this is most probably not what link.exe does. The symbol
mentioned in the commit message of
ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b would be a common symbol with a
size of around 3 GB; this is not what might have been intended.
That commit tried to avoid running into the error ".idata$4 should not
refer to special section 0"; that issue is fixed for a similar style of
section symbols in 4a4a8a1476b1386b523dc5b292ba9a5a6748a9cf.
Therefore, revert ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b and extend
the fix from 4a4a8a1476b1386b523dc5b292ba9a5a6748a9cf to also work for
the section symbols in MSVC generated import libraries.
The main detail about them, is that for symbols of type
IMAGE_SYM_CLASS_SECTION, the Value field is not an offset, but it is an
optional set of flags, corresponding to the Characteristics of the
section header (although it may be empty).
This change implements support for the /stub flag to align with MS
link.exe. This option is useful when a program needs to optimize the DOS
program that executes when the PE runs on DOS, avoiding the traditional
hardcoded DOS program in LLD.
This commit improves the memory efficiency of the lld-macho linker by
optimizing how thunks are printed in the map file. Previously, merging
vectors of input sections required creating a temporary vector, which
increased memory usage and in some cases caused the linker to run out of
memory as reported in comments on
https://github.com/llvm/llvm-project/pull/120496. The new approach
interleaves the printing of two arrays of ConcatInputSection in sorted
order without allocating additional memory for a merged array.
When LLD links against an import library (for the regular, short import
libraries), it doesn't actually link in the header/trailer object files
at all, but synthesizes new corresponding data structures into the right
sections.
If the whole of such an import library is forced to be linked, e.g. with
the -wholearchive: option, we actually end up linking in those
header/trailer objects. The header objects contain a construct which LLD
fails to handle; previously we'd error out with the error ".idata$4
should not refer to special section 0".
Within the import library header object, in the import directory we have
relocations towards the IAT (.idata$4 and .idata$5), but the header
object itself doesn't contain any data for those sections.
In the case of GNU generated import libraries, the header objects
contain zero length sections .idata$4 and .idata$5, with relocations
against them. However in the case of LLVM generated import libraries,
the sections .idata$4 and .idata$5 are not included in the list of
sections. The symbol table does contain section symbols for these
sections, but without any actual associated section. This can probably
be seen as a declaration of an empty section.
If the header/trailer objects of a short import library are linked
forcibly and we also reference other functions in the library, we end up
with two import directory entries for this DLL, one that gets
synthesized by LLD, and one from the actual header object file. This is
inelegant, but should be acceptable.
While it would seem unusual to link import libraries with the
-wholearchive: option, this can happen in certain scenarios.
Rust builds libraries that contain relevant import libraries bundled
along with compiled Rust code as regular object files, all within one
single archive. Such an archive can then end up linked with the
-wholarchive: option, if build systems decide to use such an option for
including static libraries.
This should fix https://github.com/msys2/MINGW-packages/issues/21017.
This works for the header/trailer object files in import libraries
generated by LLVM; import libraries generated by MSVC are vaguely
different. ecb5ea6a266d5cc4e05252f6db4c73613b73cc3b did an attempt at
fixing the issue for MSVC generated libraries, but it's not entirely
correct, and isn't enough for making things work for that case.
Move `LinkerDriver::addUndefined` to` SymbolTable` to allow its use with
both symbol tables on ARM64X and rename it to `addGCRoot` to clarify its
distinct role compared to the existing `SymbolTable::addUndefined`.
Command-line `-include` arguments now apply to the EC symbol table, with
`mainSymtab` introduced in `linkerMain`. There will be more similar
cases. For `.drectve` sections, the corresponding symbol table is used
based on the context.
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.
