First, do not reserve numSections in the Chunks array. In cases where
there are many non-prevailing sections, this will overallocate memory
which will not be used.
Second, free the memory for sparseChunks after initializeSymbols. After
that, it is never used.
This saves 50MB of 627MB for my use case without affecting performance.
The inlinees section contains references to the file checksum table. The
file checksum table in the PDB must have the same layout as the file
checksum table in the object file, so all the existing file id
references should stay valid.
Previously, we would do this:
for all inlined functions:
- lookup filename from checksum and string table
- make that filename absolute
- look up the new file id for that filename up in the new checksum
table
This lead to pdbMakeAbsolute and remove_dots ending up in the hot path.
We should only need to absolutify the source path once, not once every
time we process an inline function from that source file.
This speeds up linking chrome PGO stage 1 net_unittests.exe from 9.203s
to 8.500s (-7.6%). Looking just at time to process symbol records, it
goes from ~2000ms to ~1300ms, which is consistent with the overall
speedup of about 700ms. This will be less noticeable in debug builds,
which have fewer inlined functions records.
GNU ld from binutils 2.35 onwards will likely support
--export-dynamic-symbol but with different semantics.
https://sourceware.org/pipermail/binutils/2020-May/111302.html
Differences:
1. -export-dynamic-symbol is not supported
2. --export-dynamic-symbol takes a glob argument
3. --export-dynamic-symbol can suppress binding the references to the definition within the shared object if (-Bsymbolic or -Bsymbolic-functions)
4. --export-dynamic-symbol does not imply -u
I don't think the first three points can affect any user.
For the fourth point, Not implying -u can lead to some archive members unfetched.
Add -u foo to restore the previous behavior.
Exact semantics:
* -no-pie or -pie: matched non-local defined symbols will be added to the dynamic symbol table.
* -shared: matched non-local STV_DEFAULT symbols will not be bound to definitions within the shared object
even if they would otherwise be due to -Bsymbolic, -Bsymbolic-functions, or --dynamic-list.
Reviewed By: psmith
Differential Revision: https://reviews.llvm.org/D80487
LLD supports both REL and RELA for static relocations, but emits either
of REL and RELA for dynamic relocations. The relocation entry format is
specified by each psABI.
musl ld.so supports both REL and RELA. For such ld.so implementations,
REL (.rel.dyn .rel.plt) has size benefits even if the psABI chooses RELA:
sizeof(Elf64_Rel)=16 < sizeof(Elf64_Rela)=24.
* COPY, GLOB_DAT and J[U]MP_SLOT always have 0 addend. A ld.so
implementation does not need to read the implicit addend.
REL is strictly better.
* A RELATIVE has a non-zero addend. Such relocations can be packed
compactly with the RELR relocation entry format, which is out of scope
of this patch.
* For other dynamic relocation types (e.g. symbolic relocation R_X86_64_64),
a ld.so implementation needs to read the implicit addend. REL may have
minor performance impact, because reading implicit addends forces
random access reads instead of being able to blast out a bunch of
writes while chasing the relocation array.
This patch adds -z rel and -z rela to change the relocation entry format
for dynamic relocations. I have tested that a -z rel produced x86-64
executable works with musl ld.so
-z rela may be useful for debugging purposes on processors whose psABIs
specify REL as the canonical format: addends can be easily read by a tool.
Reviewed By: grimar, mcgrathr
Differential Revision: https://reviews.llvm.org/D80496
Previously in the object format we punted on this and simply wrote
zeros (and didn't include the function in the elem segment). With
this change we write a meaningful value which is the segment
relative table index of the associated function.
This matches the that wasm-ld produces in `-r` mode. This inconsistency
between the output the MC object writer and the wasm-ld object
writer could cause warnings to be emitted when reading back in the
output of `wasm-ld -r`. See:
https://github.com/emscripten-core/emscripten/issues/11217
This only applies to this one relocation type which is only generated
when compiling in PIC mode.
Differential Revision: https://reviews.llvm.org/D80774
When we originally wrote these tests we didn't have a stable and
fleshed out assembly format. Now we do so we should prefer that
over llvm ir for lld tests to avoid including more part of llvm
than necessary in order to run the test.
This change converts just 30 out of about 130 test files. More to
come when I have some more time.
Differential Revision: https://reviews.llvm.org/D80361
Summary:
Count the per-module number of basic blocks when the module summary is computed
and sum them up during Thin LTO indexing.
This is used to estimate the working set size under the partial sample PGO.
This is split off of D79831.
Reviewers: davidxl, espindola
Subscribers: emaste, inglorion, hiraditya, MaskRay, steven_wu, dexonsmith, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80403
In D34993, we discussed and concluded that we should drop `__real_
symbol from the symbol table, but I did the opposite in D50569.
This patch is to drop `__real_` symbol.
MaskRay's note: omitting `__real_` is important if it is undefined:
otherwise a subsequent link may error due to the undefined `__real_` in .dynsym
Differential Revision: https://reviews.llvm.org/D51283
Bazel created interface shared objects (.ifso) may be misaligned. We use
llvm::support::detail::packed_endian_specific_integral under the hood
which allows reading of misaligned values, so there is not a need to
diagnose (in LLD we don't intend to support sophisticated parsing for
SHT_GNU_*).
In the 64-bit ELF V2 API Specification: Power Architecture, 2.3.3.1. GPR
Save and Restore Functions defines some special functions which may be
referenced by GCC produced assembly (LLVM does not reference them).
With GCC -Os, when the number of call-saved registers exceeds a certain
threshold, GCC generates `_savegpr0_* _restgpr0_*` calls and expects the
linker to define them. See
https://sourceware.org/pipermail/binutils/2002-February/017444.html and
https://sourceware.org/pipermail/binutils/2004-August/036765.html . This
is weird because libgcc.a would be the natural place. However, the linker
generation approach has the advantage that the linker can generate
multiple copies to avoid long branch thunks. We don't consider the
advantage significant enough to complicate our trunk implementation, so
we take a simple approach.
* Check whether `_savegpr0_{14..31}` are used
* If yes, define needed symbols and add an InputSection with the code sequence.
`_savegpr1_*` `_restgpr0_*` and `_restgpr1_*` are similar.
Reviewed By: sfertile
Differential Revision: https://reviews.llvm.org/D79977
An undefined symbol in a shared object can be versioned, like `f@v1`.
We currently insert `f` as an Undefined into the symbol table, but we
should insert `f@v1` instead.
The string `v1` is inferred from SHT_GNU_versym and SHT_GNU_verneed.
This patch implements the functionality.
Failing to do this can cause two issues:
* If a versioned symbol referenced by a shared object is defined in the
executable, we will fail to export it.
* If a versioned symbol referenced by a shared object in another object
file, --no-allow-shlib-undefined may spuriously report an
"undefined reference to " error. See https://bugs.llvm.org/show_bug.cgi?id=44842
(Linking -lfftw3 -lm on Arch Linux can cause
`undefined reference to __log_finite`)
Reviewed By: grimar
Differential Revision: https://reviews.llvm.org/D80059
Summary:
This patch fixes a bug where initialization code for .bss segments was
emitted in the memory initialization function even though the .bss
segments were discounted in the datacount section and omitted in the
data section. This was producing invalid binaries due to out-of-bounds
segment indices on the memory.init and data.drop instructions that
were trying to operate on the nonexistent .bss segments.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80354
Summary:
This is a pre-requisite to parallelizing PDB symbol and type merging.
Currently this timer usage would not be thread safe.
Reviewers: aganea, MaskRay
Subscribers: jfb, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D80298
Summary:
This diff restores and builds upon @pcc and @ruiu's initial work on
subsections.
The .subsections_via_symbols directive indicates we can split each
section along symbol boundaries, unless those symbols have been marked
with `.alt_entry`.
We exercise this functionality in our tests by using order files that
rearrange those symbols.
Depends on D79668.
Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee
Reviewed By: smeenai
Subscribers: thakis, llvm-commits, pcc, ruiu
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79926
Note, we still name a preempted SharedSymbol "shared definition",
instead of "reference" as printed by GNU ld. This difference should not matter.
```
// GNU ld
ld.bfd: t: definition of f@v1
ld.bfd: t.so: reference to f@v1
```
Reviewed By: psmith
Differential Revision: https://reviews.llvm.org/D80143
This diff restores and builds upon @pcc and @ruiu's initial work on
subsections.
The .subsections_via_symbols directive indicates we can split each
section along symbol boundaries, unless those symbols have been marked
with `.alt_entry`.
We exercise this functionality in our tests by using order files that
rearrange those symbols.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D79926
The order file indicates how input sections should be sorted within each
output section, based on the symbols contained within those sections.
This diff sets the stage for implementing and testing
`.subsections_via_symbols`, where we will break up InputSections by each
symbol and sort them more granularly.
Reviewed By: smeenai
Differential Revision: https://reviews.llvm.org/D79668
Under `lld/test/Driver/Inputs/`, all instances of `libtest.a` are
unreferenced. FYI, all of these are empty archives, and the files
contain only a magic number.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D80182
This is fixing a thinLTO module collision issue for thin archives. The problem is that we always use a zero offset to name members in a thin archive and that causes the following build error:
ld.lld: error: Expected at most one ThinLTO module per bitcode file
which happens to a thin archive that has two members with the same object file name (whose paths will be ignored by thinLTO driver)
The fix here is to use real member offset instead as is done for non-thin archives.
Differential Revision: https://reviews.llvm.org/D79880
Announced on https://lists.llvm.org/pipermail/llvm-dev/2020-May/141416.html
Similar to D79371, but for `multiclass B` (convenience helper for defining --foo and --no-foo)
Some changed options are also used by gold, but I haven't seen their
one-dash use cases outside of lld's testsuite.
With this change, basic archive files can be linked together. Input
section discovery has been refactored into a function since archive
files lazily resolve their symbols / the object files containing those
symbols.
Reviewed By: int3, smeenai
Differential Revision: https://reviews.llvm.org/D78342
This paves the way to doing more things in parallel, and allows us to
order type sources in dependency order. PDBs and PCH objects have to be
loaded before object files which use them.
This is a rebase of the unapplied remaining changes in
https://reviews.llvm.org/D59226. I found it very challenging to rebase
this across the LLD variable name style change. I recall there was a
tool for that, but I didn't take the time to use it.
Reviewers: aganea, akhuang
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79672
Install a cmake config file. Copied exactly from how clang exports.
I also wasn't sure whether the canonical capitalization is "lld" or
"LLD". The project() is still calling this lld, but most places seemed
to capitalize it.
Just skip trying to match for the path separator explicitly (instead
of making it match either a forward or backwards slash), simplifying
the test a little.
Allow disabling either the full auto import feature, or just
forbidding the cases that require runtime fixups.
As long as all auto imported variables are referenced from separate
.refptr$<name> sections, we can alias them on top of the IAT entries
and don't actually need any runtime fixups via pseudo relocations.
LLVM generates references to variables in .refptr stubs, if it
isn't known that the variable for sure is defined in the same object
module. Runtime pseudo relocs are needed if the addresses of auto
imported variables are used in constant initializers though.
Fixing up runtime pseudo relocations requires the use of
VirtualProtect (which is disallowed in WinStore/UWP apps) or
VirtualProtectFromApp. To allow any risk of ambiguity, allow
rejecting cases that would require this at the linker stage.
This adds support for the --disable-runtime-pseudo-reloc and
--disable-auto-import options in the MinGW driver (matching GNU ld.bfd)
with corresponding lld private options in the COFF driver.
Differential Revision: https://reviews.llvm.org/D78923
This is a followup to https://reviews.llvm.org/D78779.
When signatures mismatch we create set of variant symbols. Some of
the fields in these symbols were not be initialized correct.
Specifically we were seeing isUsedInRegularObj not being set correctly,
leading to the symbol not getting included in the symbol table
and a crash writing relections in --reloctable mode.
There is larger refactor due here, but this is a minimal change the
fixes the bug at hand.
Differential Revision: https://reviews.llvm.org/D79756
clang passes these flags; this makes it easier to try `clang -v`
output with `ld -flavor darwinnew`.
Differential Revision: https://reviews.llvm.org/D79797
This unblocks the linking of real programs, since many core system
functions are only available as sub-libraries of libSystem.
Differential Revision: https://reviews.llvm.org/D79228
Summary:
Add the vendor macro to "lld" for extended version output support,
such that it's able to print additional version info. This is
consistent with the Clang and LLVM version printer, and the
additional version message can be provided via PACKAGE_VENDOR.
Reviewers: hubert.reinterpretcast, kbarton, cebowleratibm, rzurob, ruiu
Reviewed By: hubert.reinterpretcast
Subscribers: emaste, mgorny, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D79026
The initial attempt didn't work on Windows; apparently Powershell has a
different syntax for running commands sequentially and concatenating
their outputs. So I've created two temporary files instead.
Differential Revision: https://reviews.llvm.org/D79697
Reid Kleckner