Previously we would ignore all undefined symbols when using
`-shared` or `-pie`. All undefined symbols would be treated as imports
regardless of whether those symbols we defined in any shared library.
With this change we now track symbol in shared libraries and report
undefined symbols in the main program by default.
The old behavior is still available via the
`--unresolved-symbols=import-dynamic` command line flag.
This rationale for allowing this type of breaking change is that `-pie`
and `-shared` are both still experimental will warn as such, unless
`--experimental-pic` is passed.
As part of this change the linker now models shared library symbols
via new SharedFunctionSymbol and SharedDataSymbol types.
I've also added a new `--no-shlib-sigcheck` option that bypassed the
checking of functions signature in shared libraries. This is
specifically required by emscripten the case where the imports/exports
of shared libraries have been modified by via JS type legalization (this
is only needed when targeting old JS engines where bigint is not yet
available
See https://github.com/emscripten-core/emscripten/issues/18198
Parsing the new input file's symbols might invalidate LTO codegen, but
the semantics of deplibs require them to be parsed. Accordingly, report
an error unless the file had already been added to the link.
Fixes#56070
- Add support for `.openbsd.mutable`
(rebaser's note) adapted from:
bd249b5664
New auto-coalescing sections removed
In the linkers, collect objects in section "openbsd.mutable" and place
them into a page-aligned region in the bss, with the right markers for
kernel/ld.so to identify the region and skip making it immutable. While
here, fix readelf/objdump versions to show all of this. ok miod kettenis
- Add support for `.openbsd.syscalls`
(rebaser's note) adapted from:
42a61acefa
Collect .openbsd.syscalls sections into a new PT_OPENBSD_SYSCALLS
segment. This will be used soon to pin system calls to designated call
sites.
ok deraadt@
- Scope OpenBSD special section handling under that ELFOSABI
As a preexisting comment in `ELF/Writer.cpp` says:
> section names shouldn't be significant in ELF in spirit.
so scoping OSABI-specific magic name hacks to just the OSABI in
question limits the degree to which we deviate from that "spirit" for
all other OSABIs.
OpenBSD in particular is very fast moving, having added a number of
special sections, etc. in recent years. It is unclear how possible /
reasonable it is for upstream to implement all these features in any
event, but scoping like this at least mitigates the fallout for other
OSABIs systems which wish to be more slow-moving.
Co-authored-by: deraadt <deraadt@openbsd.org>
See the comment in handleTlsRelocation. For TLSDESC=>IE (the TLS symbol
is defined in another DSO), R_RISCV_TLSDESC_{LOAD_LO12,ADD_LO12_I,CALL}
referencing a non-preemptible label uses the `R_RELAX_TLS_GD_TO_LE` code
path.
If there is no TLS section, `getTlsTpOffset` will be called with null
`Out::tlsPhdr`, leading to a null pointer dereference. Since the return
value is used by `RISCV::relocateAlloc` and ignored there, just return
0.
LoongArch TLSDESC doesn't use STT_NOTYPE labels. The `if (..) return 0;`
is a no-op for LoongArch.
This patch is a follow-up to #79239 and fixes some comments.
Pull Request: https://github.com/llvm/llvm-project/pull/98569
This matches what is done for FreeBSD.
OpenBSD has a few special program header types, and other such ELF
extensions. Setting the ELFOSABI like so will allow LLD to support them
without needlessly impacting non-OpenBSD ELFs.
Testing strategy matches 06cecdc60ec9ebfdd4d8cdb2586d201272bdf6bd.
Take two of #98158 / b64c1de714c50bec7493530446ebf5e540d5f96a, which was
reverted in #98494 / c0261351136e4a826be697e5ebb5fa638abe7485.
Preexisting test is fixed now.
Fix#98294.
When you specify --wrap=foo, sometimes foo is undefined in any context.
If you declare __real_foo as weak, GNU ld will not attempt to find the
strong symbol foo, instead, it generates a weak undefined symbol.
This pull request imitates this behavior by copying the binding
attribute from __real_foo to foo.
`-no_objc_category_merging` flag was behaving like
`-objc_category_merging` - i.e. acting to enable category merging.
This is because we were using `hasArg` instead of `hasFlag` to test for
it. Fix this and add test to ensure it behaves as expected.
The default `dyld_chained_import` entry format only allocates 8 bits to
the library ordinal, of which values 0xF1 - 0xFF are reserved for
special ordinals (`BIND_SPECIAL_DYLIB_*` values). If there are more than
240 imported dylibs (as in the case of component builds of Chromium), we
need to switch to `dyld_chained_import_addend64`, which stores 16-bit
ordinals.
lld was using RISCVISAInfo(unsigned XLen,
RISCVISAUtils::OrderedExtensionMap &Exts). This required a call to
RISCVISAInfo::postProcessAndChecking to validate the RISCVISAInfo that
was created. This exposes too much about RISCVISAInfo to lld.
Replace with a new RISCVISAInfo::createFromExtMap that is responsible
for creating the object and calling postProcessAndChecking.
Currently we rely on detecting the source language of a class by the
name of the symbol pointing to it. This generally works, but there are
scenarios where Swift generates both an ObjC name and a Swift name for
the symbol - by aliasing the ObjC name to the Swift name, as follows:
```
.globl _OBJC_CLASS_$__TtC11MyTestClass11MyTestClass
.private_extern _OBJC_CLASS_$__TtC11MyTestClass11MyTestClass
.set _OBJC_CLASS_$__TtC11MyTestClass11MyTestClass, _$s11MyTestClassAACN
```
So to correctly detect the source language in all cases, we need to
handle scenarios where both an ObjC symbol and a Swift symbol is defined
for a class - in this case the symbol is always a Swift class.
This patch adds support for merging the atomic_abi attribute, specified
in
https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-elf.adoc#tag_riscv_atomic_abi-14-uleb128version,
to LLD.
The atomics_abi tag merging is conducted as follows:
UNKNOWN is safe to merge with all other values.
A6C is compatible with A6S, and results in the A6C ABI.
A6C is incompatible with A7, and results in an error.
A6S and A7 are compatible, and merging results in the A7 ABI.
Note: the A7 is not yet supported in either LLVM or in any current
hardware, and is therefore omitted from attribute generation in
RISCVTargetStreamer.
LLD support was split from
https://github.com/llvm/llvm-project/pull/90266
The LC_SUB_CLIENT Mach-O command and the `allowable-clients` TBD entry
specify that the given framework (or library?) can only be linked
directly from the specified names, even if it is sitting in `/usr/lib`
or `/System/Library/Frameworks`.
Add a check for those conditions before checking if a library should be
implicitly linked, and link against their umbrella if they have
allowable clients. The code needs to be in both the binary libraries and
the interface libraries.
Add a test that reproduces the scenario in which a framework reexports a
private framework that sits in `/System/Library/Frameworks`, and check
for the symbols of the reexported framework to be associated with the
public framework, and not the private one.
With `LLVM_APPEND_VC_REV=off`, the new version message after #97323
looks like:
```
% /tmp/out/custom2/bin/ld.lld --version
LLD 19.0.0, compatible with GNU linkers
```
A trailing comma after the version string might cause issues with
version detection tools that don't strip it, as seen in the Linux
kernel's scripts/ld-version.sh script.
Pull Request: https://github.com/llvm/llvm-project/pull/97942
When `-fixup_chains`/`-init_offsets` is used, a different section,
`__init_offsets` is synthesized from `__mod_init_func`. If there are any
symbols defined inside `__mod_init_func`, they are added to the symbol
table unconditionally while processing the input files. Later, when
querying these symbols' addresses (when constructing the symtab or
exports trie), we crash with a null deref, as there is no output section
assigned to them.
Just making the symbols point to `__init_offsets` is a bad idea, as the
new section stores 32-bit integers instead of 64-bit pointers; accessing
the symbols would not do what the programmer intended. We should
entirely omit them from the output. This is what ld64 and ld-prime do.
This patch uses the same mechanism as dead-stripping to mark these
symbols as not needed in the output. There might be nicer fixes than the
workaround, this is discussed in #97155.
Fixes https://github.com/llvm/llvm-project/pull/79894#issuecomment-1944092892Fixes#94716
0f9fbbb63cfcd2069441aa2ebef622c9716f8dbb changed the version printouts.
This broke linker detection in Meson, when disambiguating between the
ld.lld and lld-link interfaces, in
https://github.com/mesonbuild/meson/blob/1.4.1/mesonbuild/linkers/detect.py#L67,
which checks for the string "(compatible with GNU linkers)" including
the parentheses.
Reinstate the parentheses in the printout here, for compatibility with
Meson. The printout looks a little odd in this form, "LLD 19.0.0
(https://github.com/llvm/llvm-project
173514d58ec4e6166670f1e37a038df3865c8b96) (compatible with GNU
linkers)", but works with Meson.
The Meson check is loosened in https://github.com/mesonbuild/meson/pull/13383,
but existing versions of Meson with the too strict check will be around
for quite some time, so we should only change LLD to the new form once
older versions of Meson aren't used for these targets any longer, i.e.
earliest within a few years.
It turns out that the notes section for corefiles (or really any elf
file with multiple notes) is set up in such a way for LLVM formatted
output that the JSON equivalent only has the last note since the notes
are held in a dictionary with every key being Note. This pr alters the
layout for the notes to a list of dictionaries to sidestep this issue
for JSON output. Prior to this pr a note section in the output looked
like (for LLVM output):
```
Notes [
NoteSection {
Name: <?>
Offset: 0x2148
Size: 0x1F864
Note {
Owner: CORE
Data size: 0x150
Type: NT_PRSTATUS (prstatus structure)
Description data (
0000: 06000000 00000000 00000000 06000000 |................|
...
)
}
Note {
Owner: CORE
Data size: 0x88
Type: NT_PRPSINFO (prpsinfo structure)
Description data (
0000: 02440000 00000000 04054040 00000000 |.D........@@....|
....
```
But is now:
```
NoteSections [
NoteSection {
Name: <?>
Offset: 0x2148
Size: 0x1F864
Notes [
{
Owner: CORE
Data size: 0x150
Type: NT_PRSTATUS (prstatus structure)
Description data (
0000: 06000000 00000000 00000000 06000000 |................|
...
)
}
{
Owner: CORE
Data size: 0x88
Type: NT_PRPSINFO (prpsinfo structure)
Description data (
0000: 02440000 00000000 04054040 00000000 |.D........@@....|
...
```
Added LLVM repository and LLVM revision information for
`lld::getLLDVersion()`
Before this change:
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (compatible with GNU linkers)
```
After this change with LLVM_APPEND_VC_REV=on
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0 (https://github.com/yugier/llvm-project.git 4134b33c6a362cb462b335177d6d9e8235f04309), compatible with GNU linkers
```
with LLVM_APPEND_VC_REV=off
```
hongyuchy@hongyuchy:~/llvm-project/.build_lld_version$ bin/ld.lld --version
LLD 19.0.0, compatible with GNU linkers
```
Summary:
Currently the `--lto-emit-llvm` option writes out the
post-internalization bitcode. This is the bitcode before any
optimizations or other pipelines have been run on it. This patch changes
that to use the pre-codegen module, which is the state of the LLVM-IR
after the optimizations have been run.
I believe that this makes sense as the `--lto-emit-llvm` option seems to
imply that we should emit the final output of the LLVM pass as if it
were the desired output. This should include optimizations at the
requested optimization level. My main motivation for this change is to
be able to use this to link several LLVM-IR files into a single one that
I can then pass back to `ld.lld` later (for JIT purposes).
Currently the `tryFindDefinedOnIsec` takes in an `InputSection` and an
`offset` and is supposed to return the target symbol that is referenced
on that `InputSection` at the given offset.
However, it does not deal with the reloc `addend` and might return the
incorrect symbol.
Here we add support for handling the reloc's `addend`.
Summary:
The LTO pass currently supporting emitting LTO via the
`--plugin-opt=emit-llvm` option. However, there is a very similar option
called `--lto-emit-asm`. This patch just makes the usage more
consistent and more obvious that emitting LLVM-IR is supported.
When an undefined symbol is referenced from more than one file we were
reporting all undefined symbols as originating from just one of them.
This came up while working on
https://github.com/WebAssembly/tool-conventions/issues/158 where
undefined symbols in one object file were being reported as coming from
another.
When reference types are enabled clang will generate call_indirect
instructions that explicitly reference the global
`__indirect_function_table` symbol.
In this case the resulting global symbol was not being correctly marked
with explicit import name/module, resulting in the linker reporting
errors when it was referenced.
This issue was reported in
https://github.com/WebAssembly/tool-conventions/issues/158
The first object file whose EI_OSABI is not ELFOSABI_NONE is selected.
This is useful for some OSes to identify themselves. This achieves
similar effects to BFD emulations `ld.lld -m *_fbsd` but is more
lightweight.
Pull Request: https://github.com/llvm/llvm-project/pull/97144
An empty output section specified in the `SECTIONS` command (e.g.
`empty : { *(empty) }`) may be discarded. Due to phase ordering, we
might define `__start_empty`/`__stop_empty` symbols with incorrect
section indexes (usually benign, but could go out of bounds and cause
`readelf -s` to print `BAD`).
```
finalizeSections
addStartStopSymbols // __start_empty is defined
// __start_empty is added to .symtab
sortSections
adjustOutputSections // `empty` is discarded
writeSections
// __start_empty is Defined with an invalid section index
```
Loaders use `st_value` members of the start/stop symbols and expect no
"undefined symbol" linker error, but do not particularly care whether
the symbols are defined or undefined. Let's retain the associated empty
output section so that start/stop symbols will have correct section
indexes.
The approach allows us to remove `LinkerScript::isDiscarded`
(https://reviews.llvm.org/D114179). Also delete the
`findSection(".text")` special case from https://reviews.llvm.org/D46200,
which is unnecessary even before this patch (`elfHeader` would be fine
even with very large executables).
Note: we should be careful not to unnecessarily retain .ARM.exidx, which
would create an empty PT_ARM_EXIDX. ~40 tests would need to be updated.
---
An alternative is to discard the empty output section and keep the
start/stop symbols undefined. This approach needs more code and requires
`LinkerScript::isDiscarded` before we discard empty sections in
``adjustOutputSections`.
Pull Request: https://github.com/llvm/llvm-project/pull/96343
`.rela.dyn` is currently created outside of the `config->hasDynSymTab`
condition. In relocatable links, `.rela.dyn` will be discarded by
`removeUnusedSyntheticSections`. It's better than suppress the creation
so that .relr.auth.dyn support (#96496) does not need to adjust
`removeUnusedSyntheticSections`.
llvm/include/llvm/TextAPI/InterfaceFile.h SymbolsSet uses a
llvm::DenseMap<SymbolsMapKey, Symbol *>, which has a non-deterministic
order. For now, stabilize the order in lld since it is much simpler
than refactoring InterfaceFile.h.
In the context of #95976 it became clear that the output for readobj
implied multi valued entries in several cases in the elf headers that
the documentation only allowed for a single value. DT_NEEDED is the
example here where the value is an offset into the string table without
any sort of separator that could give you multiple entries. This patch
alters the LLVM output so that the single valued nature is emphasized.
For example the output was:
```
DynamicSection [ (35 entries)
Tag Type Name/Value
0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:]
0x0000000000000001 NEEDED Shared library: [libm.so.6]
0x0000000000000001 NEEDED Shared library: [libz.so.1]
0x0000000000000001 NEEDED Shared library: [libzstd.so.1]
```
and is now
```
Tag Type Name/Value
0x000000000000001D RUNPATH Library runpath: [$ORIGIN/../lib:]
0x0000000000000001 NEEDED Shared library: libm.so.6
0x0000000000000001 NEEDED Shared library: libz.so.1
0x0000000000000001 NEEDED Shared library: libzstd.so.1
```
This pr also tests that multi-valued rpaths are handled correctly in the
JSON case (i.e. they become proper lists) like:
```
{
"Tag": 15,
"Type": "RPATH",
"Value": 9,
"Path": [
"x",
"w",
"U"
]
},
```
when separated by :
`IsRela` is used by lld to differentiate REL and RELA static
relocations. The proposed CREL patch will reuse `IsRela` for CREL
(#91280). Rename `IsRela` to be more appropriate.
Pull Request: https://github.com/llvm/llvm-project/pull/96592
Since `assignAddresses` is executed more than once, error reporting
during `assignAddresses` would be duplicated. Generalize #66854 to cover
more errors.
Note: address-related errors exposed in one invocation might not be
errors in another invocation.
Pull Request: https://github.com/llvm/llvm-project/pull/96361
When two or more functions' signatures differ, one of them is selected
and for other signatures `unreachable` stubs are generated:
57778ec36c/lld/wasm/SymbolTable.cpp (L975)57778ec36c/lld/wasm/SymbolTable.cpp (L852-L870)
And when these `SyntheticFunction`s are generated, this constructor is
used,
57778ec36c/lld/wasm/InputChunks.h (L266-L269)
which does not set its `function` field:
57778ec36c/lld/wasm/InputChunks.h (L304)
As a result, the `function` field contains a garbage value for these
stub functions.
`InputFunction::getFunctionCodeOffset()` is called when relocations are
resolved for `.debug_info` section to get functions' PC locations. But
because these stub functions don't have their `function` field set, this
function segfaults:
57778ec36c/lld/wasm/InputChunks.h (L282)
This bug seems to be triggered when these conditions are met:
- There is a signature mismatch warning with multiple different
definitions (one definition with other declarations is not sufficient)
with weak linkage with the same name
- The 'stub' function containing unreachable has a callsite, meaning it
isn't DCE'd
- .debug_info section is generated (i.e., DWARF is used)
This PR initializes the field with `nullptr`, and in
`InputFunction::getFunctionCodeOffset`, checks if `function` is
`nullptr`, and if so, just returns 0. This function is called only for
resolving relocations in the `.debug_info` section, and addresses of
these stub functions, which are not the functions users wrote in the
first place, are not really meaningful anyway.
When `!isInt<32>(x.va)`, `addq x@GOTPCREL(%rip), %rax` (possibly due to
getelementptr of a global variable) should not be optimized to
`addq offset, %rax`. We currently have either an assertion failure or an
incorrect optimization.
Fix it using the relaxOnce framework.
SmallPtrSet.h and TimeProfiler.h are unused. CommandLine.h is only
needed for the UseNewDbgInfoFormat declare, which can be moved to the
places that need it.
For x86_64 callable functions, ARM64EC requires an entry thunk generated
by the compiler. The linker interprets .hybmp sections to associate
function chunks with their entry points and writes an offset to thunks
preceding function section contents.
Additionally, ICF needs to be aware of entry thunks to not consider
chunks to be equal when they have different entry thunks, and GC needs
to mark entry thunks together with function chunks.
I used a new SectionChunkEC class instead of storing entry thunks in
SectionChunk, following the guideline to keep SectionChunk as compact as
possible. This way, there is no memory usage increase on non-EC targets.
This change adds tracking for the source language of the various input
structs used by the category merger. Identification is based on expected
symbol names. It also adds checks to ensure we're dealing with the
expected data in known scenarios.
