Commit Graph

476 Commits

Author SHA1 Message Date
bors
2c7bc5e33c Auto merge of #87867 - bjorn3:unique_type_id_interner, r=wesleywiser
Use a separate interner type for UniqueTypeId

Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols
with the global interner. In fact the Debug implementation of
UniqueTypeId did exactly this.

Using a separate interner type also avoids prefilling the interner with
unused symbols and allow for optimizing the symbol interner for parallel
access without negatively affecting the single threaded module codegen.
2021-09-15 12:34:31 +00:00
bjorn3
8c7840e8cb Use a separate interner type for UniqueTypeId
Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols
with the global interner. In fact the Debug implementation of
UniqueTypeId did exactly this.

Using a separate interner type also avoids prefilling the interner with
unused symbols and allow for optimizing the symbol interner for parallel
access without negatively affecting the single threaded module codegen.
2021-09-13 14:42:06 +02:00
bors
51e514c0fb Auto merge of #88759 - Amanieu:panic_in_drop, r=nagisa,eddyb
Add -Z panic-in-drop={unwind,abort} command-line option

This PR changes `Drop` to abort if an unwinding panic attempts to escape it, making the process abort instead. This has several benefits:
- The current behavior when unwinding out of `Drop` is very unintuitive and easy to miss: unwinding continues, but the remaining drops in scope are simply leaked.
- A lot of unsafe code doesn't expect drops to unwind, which can lead to unsoundness:
  - https://github.com/servo/rust-smallvec/issues/14
  - https://github.com/bluss/arrayvec/issues/3
- There is a code size and compilation time cost to this: LLVM needs to generate extra landing pads out of all calls in a drop implementation. This can compound when functions are inlined since unwinding will then continue on to process drops in the callee, which can itself unwind, etc.
  - Initial measurements show a 3% size reduction and up to 10% compilation time reduction on some crates (`syn`).

One thing to note about `-Z panic-in-drop=abort` is that *all* crates must be built with this option for it to be sound since it makes the compiler assume that dropping `Box<dyn Any>` will never unwind.

cc https://github.com/rust-lang/lang-team/issues/97
2021-09-12 20:48:09 +00:00
Amanieu d'Antras
007bd17a68 Apply noreturn and nounwind LLVM attributes to callsites 2021-09-11 16:13:30 +01:00
Andreas Liljeqvist
9095cf9905 rename is_valid_for to is_valid 2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
5b2f757dae Make abi::Abi Copy and remove a *lot* of refs
fix

fix

Remove more refs and clones

fix

more

fix
2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
f5d8749f85 Remove contains_zero, respect the compiler 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
05cd48b008 Add methods for checking for full ranges to Scalar and WrappingRange
Move *_max methods back to util

change to inline instead of inline(always)

Remove valid_range_exclusive from scalar
Use WrappingRange instead

implement always_valid_for in a safer way

Fix accidental edit
2021-09-09 10:41:17 +02:00
bors
e2750baf53 Auto merge of #88499 - eddyb:layout-off, r=nagisa
Provide `layout_of` automatically (given tcx + param_env + error handling).

After #88337, there's no longer any uses of `LayoutOf` within `rustc_target` itself, so I realized I could move the trait to `rustc_middle::ty::layout` and redesign it a bit.

This is similar to #88338 (and supersedes it), but at no ergonomic loss, since there's no funky `C: LayoutOf<Ty = Ty>` -> `Ty: TyAbiInterface<C>` generic `impl` chain, and each `LayoutOf` still corresponds to one `impl` (of `LayoutOfHelpers`) for the specific context.

After this PR, this is what's needed to get `trait LayoutOf` (with the `layout_of` method) implemented on some context type:
* `TyCtxt`, via `HasTyCtxt`
* `ParamEnv`, via `HasParamEnv`
* a way to transform `LayoutError`s into the desired error type
  * an error type of `!` can be paired with having `cx.layout_of(...)` return `TyAndLayout` *without* `Result<...>` around it, such as used by codegen
  * this is done through a new `LayoutOfHelpers` trait (and so is specifying the type of `cx.layout_of(...)`)

When going through this path (and not bypassing it with a manual `impl` of `LayoutOf`), the end result is that only the error case can be customized, the query itself and the success paths are guaranteed to be uniform.

(**EDIT**: just noticed that because of the supertrait relationship, you cannot actually implement `LayoutOf` yourself, the blanket `impl` fully covers all possible context types that could ever implement it)

Part of the motivation for this shape of API is that I've been working on querifying `FnAbi::of_*`, and what I want/need to introduce for that looks a lot like the setup in this PR - in particular, it's harder to express the `FnAbi` methods in `rustc_target`, since they're much more tied to `rustc` concepts.

r? `@nagisa` cc `@oli-obk` `@bjorn3`
2021-09-05 16:14:41 +00:00
bors
d32dc80bb6 Auto merge of #88559 - bjorn3:archive_logic_dedup, r=cjgillot
Move add_rlib and add_native_library to cg_ssa

This deduplicates logic between codegen backends.

cc `@antoyo` and `@khyperia` for cg_gcc and rust-gpu.
2021-09-05 04:37:12 +00:00
bors
226e181b80 Auto merge of #88550 - dpaoliello:dpaoliello/allocdebuginfo, r=estebank
Include debug info for the allocator shim

Issue Details:
In some cases it is necessary to generate an "allocator shim" to forward various Rust allocation functions (e.g., `__rust_alloc`) to an underlying function (e.g., `malloc`). However, since this allocator shim is a manually created LLVM module it is not processed via the normal module processing code and so no debug info is generated for it (if debugging info is enabled).

Fix Details:
* Modify the `debuginfo` code to allow creating debug info for a module without a `CodegenCx` (since it is difficult, and expensive, to create one just to emit some debug info).
* After creating the allocator shim add in basic debug info.
2021-09-04 12:27:45 +00:00
bors
97f2698484 Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebank
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix.

This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in https://github.com/rust-lang/rust/pull/83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #70642 partially undid that functionality with nobody objecting).

The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in #70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output.

In the future we might want to give more fine-grained control over this behavior via compiler flags (see https://github.com/rust-lang/rfcs/pull/3127 for a related RFC). For now this PR is intended as a regression fix.

This PR is an alternative to https://github.com/rust-lang/rust/pull/88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642.

Fixes https://github.com/rust-lang/rust/issues/87745.

cc `@cbeuw`
r? `@ghost`
2021-09-03 00:23:10 +00:00
Eduard-Mihai Burtescu
f53c93cf65 ty::layout: split LayoutOf into required and (blanket) provided halves. 2021-09-02 01:17:14 +03:00
Eduard-Mihai Burtescu
1e02262dcc ty::layout: implement layout_of automatically as a default method. 2021-09-02 01:17:14 +03:00
Eduard-Mihai Burtescu
4ce933f13f rustc_target: move LayoutOf to ty::layout. 2021-09-02 01:17:14 +03:00
bjorn3
977f279553 Move add_rlib and add_native_library to cg_ssa
This deduplicates logic between codegen backends
2021-09-01 14:43:27 +02:00
Mara Bos
494c563f3b
Rollup merge of #88350 - programmerjake:add-ppc-cr-xer-clobbers, r=Amanieu
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC

Fixes #88315
2021-09-01 09:23:26 +02:00
Daniel Paoliello
77a96ed564 Include debug info for the allocator shim
Issue Details:
In some cases it is necessary to generate an "allocator shim" to forward various Rust allocation functions (e.g., `__rust_alloc`) to an underlying function (e.g., `malloc`). However, since this allocator shim is a manually created LLVM module it is not processed via the normal module processing code and so no debug info is generated for it (if debugging info is enabled).

Fix Details:
* Modify the `debuginfo` code to allow creating debug info for a module without a `CodegenCx` (since it is difficult, and expensive, to create one just to emit some debug info).
* After creating the allocator shim add in basic debug info.
2021-08-31 15:24:20 -07:00
bors
9556d7a09a Auto merge of #88337 - eddyb:field-failure-is-not-an-option, r=nagisa
rustc_target: `TyAndLayout::field` should never error.

This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:

If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).

The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.

And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).

<hr/>

Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.

cc `@nagisa` `@oli-obk`
2021-08-29 22:54:26 +00:00
bors
84b0183412 Auto merge of #88388 - ldm0:outliner, r=nikic
Revert "Disable the machine outliner by default"

The fix commit is already in the fork: https://github.com/rust-lang/llvm-project/commit/6c78dbd4ca1f
Linked:
- https://github.com/rust-lang/rust/issues/85351
- https://github.com/rust-lang/rust/pull/86020
2021-08-28 13:10:26 +00:00
bors
2031fd6e46 Auto merge of #88245 - Sl1mb0:s390-asm, r=Amanieu
S390x inline asm

This adds register definitions and constraint codes for the s390x general and floating point registers necessary for fixing #85931; as well as a few tests.

Further testing is needed, but I am a little unsure of what specific tests should be added to `src/test/assembly/asm/s390x.rs` to address this.
2021-08-28 08:04:41 +00:00
liudingming
bf2f6656bc Revert machine outliner disabling on LLVM 13 2021-08-28 15:11:46 +08:00
Eduard-Mihai Burtescu
8486571a10 rustc_target: rename TyAndLayoutMethods to TyAbiInterface. 2021-08-27 13:09:32 +03:00
Eduard-Mihai Burtescu
83d986aa28 rustc_target: add lifetime parameter to LayoutOf. 2021-08-27 13:09:32 +03:00
Michael Woerister
af1b65cb18 Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. 2021-08-27 11:50:44 +02:00
bors
517c28e421 Auto merge of #87280 - lcnr:lazy-anon-const-default-substs, r=nikomatsakis
lazily "compute" anon const default substs

Continuing the work of #83086, this implements the discussed solution for the [unused substs problem](https://github.com/rust-lang/project-const-generics/blob/master/design-docs/anon-const-substs.md#unused-substs). As of now, anonymous constants inherit all of their parents generics, even if they do not use them, e.g. in `fn foo<T, const N: usize>() -> [T; N + 1]`, the array length has `T` as a generic parameter even though it doesn't use it. These *unused substs* cause some backwards incompatible, and imo incorrect behavior, e.g. #78369.

---
We do not actually filter any generic parameters here and the `default_anon_const_substs` query still a dummy which only checks that
- we now prevent the previously existing query cycles and are able to call `predicates_of(parent)` when computing the substs of anonymous constants
- the default anon consts substs only include the typeflags we assume it does.

Implementing that filtering will be left as future work.

---

The idea of this PR is to delay the creation of the anon const substs until after we've computed `predicates_of` for the parent of the anon const. As the predicates of the parent can however contain the anon const we still have to create a `ty::Const` for it.

We do this by changing the substs field of `ty::Unevaluated` to an option and modifying accesses to instead call the method `unevaluated.substs(tcx)` which returns the substs as before. If the substs - now `substs_` -  of `ty::Unevaluated` are `None`, it means that the anon const currently has its default substs, i.e. the substs it has when first constructed, which are the generic parameters it has available. To be able to call `unevaluated.substs(tcx)` in a `TypeVisitor`, we add the non-defaulted method `fn tcx_for_anon_const_substs(&self) -> Option<TyCtxt<'tcx>>`. In case `tcx_for_anon_const_substs` returns `None`, unknown anon const default substs are skipped entirely.

Even when `substs_` is `None` we still have to treat the constant as if it has its default substs. To do this, `TypeFlags` are modified so that it is clear whether they can still change when *exposing* any anon const default substs. A new flag, `HAS_UNKNOWN_DEFAULT_CONST_SUBSTS`, is added in case some default flags are missing.

The rest of this PR are some smaller changes to either not cause cycles by trying to access the default anon const substs too early or to be able to access the `tcx` in previously unused locations.

cc `@rust-lang/project-const-generics`
r? `@nikomatsakis`
2021-08-26 22:26:23 +00:00
bors
ad02dc46ba Auto merge of #87194 - eddyb:const-value-mangling, r=michaelwoerister,oli-obk
rustc_symbol_mangling: support structural constants and &str in v0.

This PR should unblock #85530 (except for float `const` generics, which AFAIK should've never worked).
(cc `@tmiasko` could the https://github.com/rust-lang/rust/pull/85530#issuecomment-857855379 failures be retried with a quick crater "subset" run of this PR + changing the default to `v0`? Just to make sure I didn't miss anything other than the floats)

The encoding is the one suggested before in e.g. https://github.com/rust-lang/rust/issues/61486#issuecomment-878932102, tho this PR won't by itself finish #61486, before closing that we'd likely want to move to `@oli-obk's` "valtrees" (i.e. #83234 and other associated work).

<hr>

**EDITs**:
1. switched unit/tuple/braced-with-named-fields `<const-fields>` prefixes from `"u"`/`"T"`/`""` to `"U"`/`"T"`/`"S"` to avoid the ambiguity reported by `@tmiasko` in https://github.com/rust-lang/rust/pull/87194#issuecomment-884279921.

2. `rustc-demangle` PR: https://github.com/alexcrichton/rustc-demangle/pull/55

3. RFC amendment PR: https://github.com/rust-lang/rfcs/pull/3161
    * also removed the grammar changes included in that PR, from this description

4. added tests (temporarily using my fork of `rustc-demangle`)

<hr>

r? `@michaelwoerister`
2021-08-26 19:15:09 +00:00
lcnr
f3996f6a88 review 2021-08-26 11:14:31 +02:00
lcnr
ab9108b70f update TypeFlags to deal with missing ct substs 2021-08-26 11:00:30 +02:00
Jacob Lifshay
5802f60355 add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC
Fixes #88315
2021-08-25 22:08:27 -07:00
Erik Desjardins
c9599c4cac improve comment 2021-08-25 17:49:28 -04:00
Erik Desjardins
5e81d643d9 don't generate partially-undef consts 2021-08-25 17:49:28 -04:00
Erik Desjardins
4d635fdf63 use undef for uninitialized bytes in constants 2021-08-25 17:49:28 -04:00
bors
e5484cec0e Auto merge of #88242 - bonega:allocation_range, r=oli-obk
Use custom wrap-around type instead of RangeInclusive

Two reasons:

1. More memory is allocated than necessary for `valid_range` in `Scalar`. The range is not used as an iterator and `exhausted` is never used.
2. `contains`, `count` etc. methods in `RangeInclusive` are doing very unhelpful(and dangerous!) things when used as a wrap-around range. - In general this PR wants to limit potentially confusing methods, that have a low probability of working.

Doing a local perf run, every metric shows improvement except for instructions.
Max-rss seem to have a very consistent improvement.

Sorry - newbie here, probably doing something wrong.
2021-08-25 02:17:41 +00:00
Eduard-Mihai Burtescu
f8810ee171 Update rustc-demangle to 0.1.21. 2021-08-24 19:53:20 +03:00
Mara Bos
5cf025f076
Rollup merge of #88230 - steffahn:a_an, r=oli-obk
Fix typos “a”→“an”

Fix typos in comments; found using a regex to find some easy instance of incorrect usage of a vs. an.

While automation was used to find these, every change was checked manually.

Changes in submodules get separate PRs:
* https://github.com/rust-lang/stdarch/pull/1201
* https://github.com/rust-lang/cargo/pull/9821
* https://github.com/rust-lang/miri/pull/1874
* https://github.com/rust-lang/rls/pull/1746
* https://github.com/rust-analyzer/rust-analyzer/pull/9984
  _folks @ rust-analyzer are fast at merging…_
  * https://github.com/rust-analyzer/rust-analyzer/pull/9985
  * https://github.com/rust-analyzer/rust-analyzer/pull/9987
  * https://github.com/rust-analyzer/rust-analyzer/pull/9989

_For `clippy`, I don’t know if the changes should better better be moved to a PR to the original repo._

<hr>

This has some overlap with #88226, but neither is a strict superset of the other.

If you want multiple commits, I can split it up; in that case, make sure to suggest a criterion for splitting.
2021-08-23 20:45:49 +02:00
Andreas Liljeqvist
e8e6d9bd86 Rename to WrappingRange 2021-08-23 14:24:34 +02:00
Andreas Liljeqvist
70433955f4 implement contains_zero method 2021-08-23 14:20:38 +02:00
bors
558553272d Auto merge of #88200 - pcwalton:no-dso-local-on-mach-o, r=nagisa
Stop emitting the `dso_local` LLVM attribute for external symbols under the static relocation model on macOS.

This matches Clang's behavior:

973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1038-L1040)

Even if `dso_local` were properly supported in this way on macOS, it seems
incorrect to add this annotation as liberally as we did. The `dso_local`
annotation is for symbols that ultimately end up in the same linkage unit, but
we were adding this annotation even for `static` values inside `extern` blocks
marked with `#[link(type="framework")]`, which should be considered dynamically
linked.  Note that Clang likewise avoids emitting `dso_local` for `dllimport`
symbols:

973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1005-L1007)

This issue caused breakage in the `ring` crate, which links to a symbol defined
in `Security.framework` that ultimately resolves to address `0x0`:

b94d61e044/src/rand.rs (L390)

For this symbol, the use of `dso_local` causes LLVM to emit a relocation of
type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the
binary is large enough, `0x0` might be out of range, and the link will fail.
Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation
of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset
and cause the link to succeed.

As a side note, the static relocation model is effectively deprecated for
security reasons on macOS, as it prohibits PIE. It's also completely
unsupported on Apple Silicon, so I don't think it's worth going to the effort
of properly supporting this model on that platform.
2021-08-22 23:44:48 +00:00
linux1
5f5afba5fb Feat: added s390x reg-definitions, constraint codes, and tests 2021-08-22 17:55:03 -04:00
linux1
f28793dd13 Feat: added inline asm support for s390x 2021-08-22 17:55:03 -04:00
Andreas Liljeqvist
5a501f73ff Use custom wrap-around type instead of Range 2021-08-22 21:46:03 +02:00
Frank Steffahn
2f9ddf3bc7 Fix typos “an”→“a” and a few different ones that appeared in the same search 2021-08-22 18:15:49 +02:00
Frank Steffahn
be9d2699ca Fix more “a”/“an” typos 2021-08-22 16:35:29 +02:00
Frank Steffahn
bf88b113ea Fix typos “a”→“an” 2021-08-22 15:35:11 +02:00
bors
db002a06ae Auto merge of #87570 - nikic:llvm-13, r=nagisa
Upgrade to LLVM 13

Work in progress update to LLVM 13. Main changes:

 * InlineAsm diagnostics reported using SrcMgr diagnostic kind are now handled. Previously these used a separate diag handler.
 * Codegen tests are updated for additional attributes.
 * Some data layouts have changed.
 * Switch `#[used]` attribute from `llvm.used` to `llvm.compiler.used` to avoid SHF_GNU_RETAIN flag introduced in https://reviews.llvm.org/D97448, which appears to trigger a bug in older versions of gold.
 * Set `LLVM_INCLUDE_TESTS=OFF` to avoid Python 3.6 requirement.

Upstream issues:

 * ~~https://bugs.llvm.org/show_bug.cgi?id=51210 (InlineAsm diagnostic reporting for module asm)~~ Fixed by 1558bb80c0.
 * ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by 81b106584f.
 * https://bugs.llvm.org/show_bug.cgi?id=51207 (Can't set custom section flags anymore). Problematic change reverted in our fork, https://reviews.llvm.org/D107216 posted for upstream revert.
 * https://bugs.llvm.org/show_bug.cgi?id=51211 (Regression in codegen for #83623). This is an optimization regression that we may likely have to eat for this release. The fix for #83623 was based on an incorrect premise, and this needs to be properly addressed in the MergeICmps pass.

The [compile-time impact](https://perf.rust-lang.org/compare.html?start=ef9549b6c0efb7525c9b012148689c8d070f9bc0&end=0983094463497eec22d550dad25576a894687002) is mixed, but quite positive as LLVM upgrades go.

The LLVM 13 final release is scheduled for Sep 21st. The current nightly is scheduled for stable release on Oct 21st.

r? `@ghost`
2021-08-21 09:25:28 +00:00
Nikita Popov
306259c645 Always use llvm.used for coverage symbols
This follows what clang does in CoverageMappingGen. Using just
llvm.compiler.used is insufficient at least for MSVC targets.
2021-08-21 10:08:05 +02:00
Patrick Walton
c17b1904a9 Stop emitting the dso_local LLVM attribute for external symbols under the static relocation model on macOS.
This matches Clang's behavior:

973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1038-L1040)

Even if `dso_local` were properly supported in this way on macOS, it seems
incorrect to add this annotation as liberally as we did. The `dso_local`
annotation is for symbols that ultimately end up in the same linkage unit, but
we were adding this annotation even for `static` values inside `extern` blocks
marked with `#[link(type="framework")]`, which should be considered dynamically
linked.  Note that Clang likewise avoids emitting `dso_local` for `dllimport`
symbols:

973cb2c326/clang/lib/CodeGen/CodeGenModule.cpp (L1005-L1007)

This issue caused breakage in the `ring` crate, which links to a symbol defined
in `Security.framework` that ultimately resolves to address `0x0`:

b94d61e044/src/rand.rs (L390)

For this symbol, the use of `dso_local` causes LLVM to emit a relocation of
type `X86_64_RELOC_SIGNED`, which is a 32-bit signed PC-relative offset. If the
binary is large enough, `0x0` might be out of range, and the link will fail.
Avoiding `dso_local` causes LLVM to use the GOT instead, emitting a relocation
of type `X86_64_RELOC_GOT_LOAD`, which will properly handle the large offset
and cause the link to succeed.

As a side note, the static relocation model is effectively deprecated for
security reasons on macOS, as it prohibits PIE. It's also completely
unsupported on Apple Silicon, so I don't think it's worth going to the effort
of properly supporting this model on that platform.
2021-08-20 17:10:41 -07:00
Nikita Popov
6a454edce9 Dispose LLVM context after TargetMachine
The TargetMachine may be referencing data in the context. In
particular, at least the GlobalISel instruction selector stored
in the TM may reference a TrackedMDNode DebugLoc that destruction
of the TargetMachine will try to untrack.
2021-08-16 18:28:18 +02:00
Nikita Popov
7c015648dd Use llvm.compiler.used insetad of llvm.used
The #[used] attribute explicitly only requires symbols to be
retained in object files, but allows the linker to drop them
if dead. This corresponds to llvm.compiler.used semantics.

The motivation to change this *now* is that https://reviews.llvm.org/D97448
starts emitting #[used] symbols into unique sections with
SHF_GNU_RETAIN flag. This triggers a bug in some version of gold,
resulting in the ARGV_INIT_ARRAY symbol part of the .init_array
section to be incorrectly placed.
2021-08-16 18:28:18 +02:00