[ELF] Handle GCC collect2 -plugin-opt= on Windows

Follows up on commit cd5d5ce235081005173566c99c592550021de058 by
additionally ignoring relative paths ending in "lto-wrapper.exe" as
can be the case

[ELF] Handle GCC collect2 -plugin-opt= on Windows

Follows up on commit cd5d5ce235081005173566c99c592550021de058 by
additionally ignoring relative paths ending in "lto-wrapper.exe" as
can be the case for GCC cross-compiled for Windows.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D138065

(cherry picked from commit cf4f35b78871aecc21e663067c57e60595bd7197)

show more ...

[ELF] Support --package-metadata

This was recently introduced in GNU linkers and it makes sense for
ld.lld to have the same support. This implementation omits checking if
the input string is valid j

[ELF] Support --package-metadata

This was recently introduced in GNU linkers and it makes sense for
ld.lld to have the same support. This implementation omits checking if
the input string is valid json to reduce size bloat.

Differential Revision: https://reviews.llvm.org/D131439

(cherry picked from commit dbd04b853b680b0a383e5f58edf3643364f67bdf)

show more ...

[ELF] Keep only getTarget() call. NFC

The place from D61712 seems unneeded now. We can just use the place added by
D62609 (support AArch64 BTI/PAC).

(cherry picked from commit e89d6d2ac527f973c4356

[ELF] Keep only getTarget() call. NFC

The place from D61712 seems unneeded now. We can just use the place added by
D62609 (support AArch64 BTI/PAC).

(cherry picked from commit e89d6d2ac527f973c43563373dfdeb9e4c3bbcc5)

show more ...

[ELF] addLibrary: fix a use-after-free bug in archiveName

It manifests as an incorrect name in --print-archive-stats=.

[ELF] Simplify --build-id/--color-diagnostics with AliasArgs. NFC

[ELF] Optimize some non-constant alignTo with alignToPowerOf2. NFC

My x86-64 lld executable is 2KiB smaller. .eh_frame writing gets faster as there
were lots of divisions.

[ELF] Internalize isBitcode. NFC

[ELF] Simplify createObjectFile/createLazyFile. NFC

And avoid redundant identify_magic test.

[NFC] Refactor llvm::zlib namespace

* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
*

[NFC] Refactor llvm::zlib namespace

* Refactor compression namespaces across the project, making way for a possible
introduction of alternatives to zlib compression.
Changes are as follows:
* Relocate the `llvm::zlib` namespace to `llvm::compression::zlib`.

Reviewed By: MaskRay, leonardchan, phosek

Differential Revision: https://reviews.llvm.org/D128953

show more ...

[LTO][ELF] Add selective --save-temps= option

Allows specific “temps” to be saved, instead of the current all-or-nothing nature of --save-temps. Multiple of these “temps” can be saved by specifying

[LTO][ELF] Add selective --save-temps= option

Allows specific “temps” to be saved, instead of the current all-or-nothing nature of --save-temps. Multiple of these “temps” can be saved by specifying the argument multiple times.

Differential Revision: https://reviews.llvm.org/D127778

show more ...

[ELF] Move InputFiles global variables (memoryBuffers, objectFiles, etc) into Ctx. NFC

[ELF] Move whyExtract/backwardReferences from LinkerDriver to Ctx. NFC

Ctx was recently added as a more suitable place for such singletons.

[lld, ELF and mac] Add --time-trace=<file>, remove --time-trace-file=<file>

`--time-trace=foo` has the same behavior as `--time-trace --time-trace-file=<file>`
had previously.

Also, for mac, make -

[lld, ELF and mac] Add --time-trace=<file>, remove --time-trace-file=<file>

`--time-trace=foo` has the same behavior as `--time-trace --time-trace-file=<file>`
had previously.

Also, for mac, make --time-trace-granularity *not* imply --time-trace, to match
behavior of the ELF port.

Differential Revision: https://reviews.llvm.org/D128451

show more ...

[ThinLTO][ELF] Add --thinlto-emit-index-files option

Allows ThinLTO indices to be written to disk on-the-fly/as-part-of “normal” linker execution. Previously ThinLTO indices could be written via --t

[ThinLTO][ELF] Add --thinlto-emit-index-files option

Allows ThinLTO indices to be written to disk on-the-fly/as-part-of “normal” linker execution. Previously ThinLTO indices could be written via --thinlto-index-only but that would cause the linker to exit early. For MLGO specifically, this enables saving the ThinLTO index files without having to restart the linker to collect data only available at later stages (i.e. output of --save-temps) of the linker's execution.

Note, this option does not currently work with:
--thinlto-object-suffix-replace, as this is intended to be used to consume minimized IR bitcode files while --thinlto-emit-index-files is intended to be run together with InProcessThinLTO (which cannot parse minimized IR).
--thinlto-prefix-replace support is left unimplemented but can be implemented if needed

Differential Revision: https://reviews.llvm.org/D127777

show more ...

Don't use Optional::hasValue (NFC)

LTO: Decide upfront whether to use opaque/non-opaque pointer types

LTO code may end up mixing bitcode files from various sources varying in
their use of opaque pointer types. The current strategy to

LTO: Decide upfront whether to use opaque/non-opaque pointer types

LTO code may end up mixing bitcode files from various sources varying in
their use of opaque pointer types. The current strategy to decide
between opaque / typed pointers upon the first bitcode file loaded does
not work here, since we could be loading a non-opaque bitcode file first
and would then be unable to load any files with opaque pointer types
later.

So for LTO this:
- Adds an `lto::Config::OpaquePointer` option and enforces an upfront
decision between the two modes.
- Adds `-opaque-pointers`/`-no-opaque-pointers` options to the gold
plugin; disabled by default.
- `--opaque-pointers`/`--no-opaque-pointers` options with
`-plugin-opt=-opaque-pointers`/`-plugin-opt=-no-opaque-pointers`
aliases to lld; disabled by default.
- Adds an `-lto-opaque-pointers` option to the `llvm-lto2` tool.
- Changes the clang driver to pass `-plugin-opt=-opaque-pointers` to
the linker in LTO modes when clang was configured with opaque
pointers enabled by default.

This fixes https://github.com/llvm/llvm-project/issues/55377

Differential Revision: https://reviews.llvm.org/D125847

show more ...

[ELF] Support -plugin-opt=stats-file=

This flag is added by clang::driver::tools::addLTOOptions() and was causing
errors for me when building the llvm-test-suite repository with LTO and
-DTEST_SUITE

[ELF] Support -plugin-opt=stats-file=

This flag is added by clang::driver::tools::addLTOOptions() and was causing
errors for me when building the llvm-test-suite repository with LTO and
-DTEST_SUITE_COLLECT_STATS=ON. This replaces the --stats-file= option
added in 1c04b52b2594d403f739ed919ef420b1e47ae343 since the flag is only
used for LTO and should therefore be in the -plugin-opt= namespace.

Additionally, this commit fixes the `REQUIRES: asserts` that was added in
948d05324a150a5a24e93bad07c9090d5b8bd129: the feature was never defined in
the lld test suite so it effectively disabled the test.

Reviewed By: MaskRay, MTC

Differential Revision: https://reviews.llvm.org/D124105

show more ...

[ELF] Prevent LTO stripping of wrapped script-referenced symbols

After 1af25a986069f2ae8c724133fa8649bb795a7925, we stop unconditionally
retaining wrapped symbols, which means that LTO's summary-bas

[ELF] Prevent LTO stripping of wrapped script-referenced symbols

After 1af25a986069f2ae8c724133fa8649bb795a7925, we stop unconditionally
retaining wrapped symbols, which means that LTO's summary-based global
dead stripping can eliminate them even if they'll be referenced by a
linker script after the wrapping is performed. Mark symbols referenced
in linker scripts as `referenced` in addition to `isUsedInRegularObj`,
so that the wrapping logic correctly sets `referencedAfterWrap` for the
symbols which will be referenced after wrapping, which will prevent LTO
from eliminating them.

An alternative would have been to change the `referencedAfterWrap` logic
to look at `isUsedInRegularObj` in addition to `referenced`, but
`isUsedInRegularObj` is also set in other places (e.g. for the entry
symbol), and it's not clear that we want `referencedAfterWrap` to take
all those places into account, so it seemed better to keep that logic
as-is and instead set `referenced` for linker script-referenced symbols.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D124433

show more ...

[ELF] Drop unused original symbol after wrapping if not defined

We were previously only omitting the original of a wrapped symbol if it
was not used by an object file and undefined. We can tighten t

[ELF] Drop unused original symbol after wrapping if not defined

We were previously only omitting the original of a wrapped symbol if it
was not used by an object file and undefined. We can tighten the second
condition to drop any symbol that isn't defined instead, which lets us
drop a previous check (added in https://reviews.llvm.org/D118756) that
was only covering some such symbols.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D124065

show more ...

[ELF] Fix wrapping symbols produced during LTO codegen

We were previously not correctly wrapping symbols that were only
produced during LTO codegen and unreferenced before then, or symbols
only refe

[ELF] Fix wrapping symbols produced during LTO codegen

We were previously not correctly wrapping symbols that were only
produced during LTO codegen and unreferenced before then, or symbols
only referenced from such symbols. The root cause was that we weren't
marking the wrapped symbol as used if we only saw the use after LTO
codegen, leading to the failed wrapping.

Fix this by explicitly tracking whether a symbol will become referenced
after wrapping is done. We can use this property to tell LTO to preserve
such symbols, instead of overload isUsedInRegularObj for this purpose.
Since we're no longer setting isUsedInRegularObj for all symbols which
will be wrapped, its value at the time of performing the wrapping in the
symbol table will accurately reflect whether the symbol was actually
used in an object (including in an LTO-generated object), and we can
propagate that value to the wrapped symbol and thereby ensure we wrap
correctly.

This incorrect wrapping was the only scenario I was aware of where we
produced an invalid PLT relocation, which D123985 started diagnosing,
and with it fixed, we lose the test for that diagnosis. I think it's
worth keeping the diagnosis though, in case we run into other issues in
the future which would be caught by it.

Fixes PR50675.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D124056

show more ...

[lld] Remove support for legacy pass manager

This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.

[lld] Remove support for legacy pass manager

This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.

Differential Revision: https://reviews.llvm.org/D123219

show more ...

[cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option

Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does

[cmake] Remove LLVM_ENABLE_NEW_PASS_MANAGER cmake option

Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.

I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.

Differential Revision: https://reviews.llvm.org/D123126

show more ...

[ELF][MTE] Add --android-memtag-* options to synthesize ELF notes

This ELF note is aarch64 and Android-specific. It specifies to the
dynamic loader that specific work should be scheduled to enable M

[ELF][MTE] Add --android-memtag-* options to synthesize ELF notes

This ELF note is aarch64 and Android-specific. It specifies to the
dynamic loader that specific work should be scheduled to enable MTE
protection of stack and heap regions.

Current synthesis of the ".note.android.memtag" ELF note is done in the
Android build system. We'd like to move that to the compiler. This patch
adds the --memtag-stack, --memtag-heap, and --memtag-mode={async, sync,
none} flags to the linker, which synthesises the note for us.

Future changes will add -fsanitize=memtag* flags to clang which will
pass these through to lld.

Depends on D119381.

Differential Revision: https://reviews.llvm.org/D119384

show more ...

[ELF] Default to --no-fortran-common

D86142 introduced --fortran-common and defaulted it to true (matching GNU ld
but deviates from gold/macOS ld64). The default state was motivated by transparently

[ELF] Default to --no-fortran-common

D86142 introduced --fortran-common and defaulted it to true (matching GNU ld
but deviates from gold/macOS ld64). The default state was motivated by transparently
supporting some FORTRAN 77 programs (Fortran 90 deprecated common blocks).
Now I think it again. I believe we made a mistake to change the default:

* this is a weird and legacy rule, though the breakage is very small
* --fortran-common introduced complexity to parallel symbol resolution and will slow down it
* --fortran-common more likely causes issues when users mix COMMON and
STB_GLOBAL definitions (see https://github.com/llvm/llvm-project/issues/48570 and
https://maskray.me/blog/2022-02-06-all-about-common-symbols).
I have seen several issues in our internal projects and Android.
On the other hand, --no-fortran-common is safer since
COMMON/STB_GLOBAL have the same semantics related to archive member extraction.

Therefore I think we should switch back, not punishing the common uage.
A platform wanting --fortran-common can implement ld.lld as a shell script
wrapper around `lld -flavor gnu --fortran-common "$@"`.

Reviewed By: ikudrin, sfertile

Differential Revision: https://reviews.llvm.org/D122450

show more ...

Reland "[ELF] Enable new passmanager plugin support for LTO"

This is the orignal patch + a check that LLVM_BUILD_EXAMPLES is enabled before
adding a dependency on the 'Bye' example pass.

Original s

Reland "[ELF] Enable new passmanager plugin support for LTO"

This is the orignal patch + a check that LLVM_BUILD_EXAMPLES is enabled before
adding a dependency on the 'Bye' example pass.

Original summary:

Add cli options for new passmanager plugin support to lld.

Currently it is not possible to load dynamic NewPM plugins with lld. This is an
incremental update to D76866. While that patch only added cli options for
llvm-lto2, this adds them for lld as well. This is especially useful for running
dynamic plugins on the linux kernel with LTO.

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D120490

show more ...