Commit Graph

940 Commits

Author SHA1 Message Date
Daniel Paoliello
cc49c3e582 Implementation of import_name_type 2022-08-26 09:15:35 -07:00
Matthias Krüger
0b19a185db
Rollup merge of - cuviper:drop-llvm-12, r=nagisa
Update the minimum external LLVM to 13

With this change, we'll have stable support for LLVM 13 through 15 (pending release).
For reference, the previous increase to LLVM 12 was .

r? `@nagisa`
2022-08-16 06:05:57 +02:00
Matthias Krüger
f347c42461
Rollup merge of - ridwanabdillahi:instr_profile_output, r=wesleywiser
Add support for generating unique profraw files by default when using `-C instrument-coverage`

Currently, enabling the rustc flag `-C instrument-coverage` instruments the given crate and by default uses the naming scheme `default.profraw` for any instrumented profile files generated during the execution of a binary linked against this crate. This leads to multiple binaries being executed overwriting one another and causing only the last executable run to contain actual coverage results.

This can be overridden by manually setting the environment variable `LLVM_PROFILE_FILE` to use a unique naming scheme.

This PR adds a change to add support for a reasonable default for rustc to use when enabling coverage instrumentation similar to how the Rust compiler treats generating these same `profraw` files when PGO is enabled.

The new naming scheme is set to `default_%m_%p.profraw` to ensure the uniqueness of each file being generated using [LLVMs special pattern strings](https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#running-the-instrumented-program).

Today the compiler sets the default for PGO `profraw` files to `default_%m.profraw` to ensure a unique file for each run. The same can be done for the instrumented profile files generated via the `-C instrument-coverage` flag as well which LLVM has API support for.

Linked Issue: https://github.com/rust-lang/rust/issues/100381

r? `@wesleywiser`
2022-08-16 06:05:56 +02:00
bors
4916e2b9e6 Auto merge of - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser
debuginfo: Generalize C++-like encoding for enums.

The updated encoding should be able to handle niche layouts where more than one variant has fields (as introduced in https://github.com/rust-lang/rust/pull/94075).

The new encoding is more uniform as there is no structural difference between direct-tag, niche-tag, and no-tag layouts anymore. The only difference between those cases is that the "dataful" variant in a niche-tag enum will have a `(start, end)` pair denoting the tag range instead of a single value.

The new encoding now also supports 128-bit tags, which occur in at least some standard library types. These tags are represented as `u64` pairs so that debuggers (which don't always have support for 128-bit integers) can reliably deal with them. The downside is that this adds quite a bit of complexity to the encoding and especially to the corresponding NatVis.

The new encoding seems to increase the size of (x86_64-pc-windows-msvc) debuginfo by 10-15%. The size of binaries is not affected (release builds were built with `-Cdebuginfo=2`, numbers are in kilobytes):

EXE | before | after | relative
-- | -- | -- | --
cargo (debug) | 40453 | 40450 | +0%
ripgrep (debug) | 10275 | 10273 | +0%
cargo (release) | 16186 | 16185 | +0%
ripgrep (release) | 4727 | 4726 | +0%

PDB | before | after | relative
-- | -- | -- | --
cargo (debug) | 236524 | 261412 | +11%
ripgrep (debug) | 53140 | 59060 | +11%
cargo (release) | 148516 | 169620 | +14%
ripgrep (release) | 10676 | 11804 | +11%

Given that the new encoding is more general, this is to be expected. Only platforms using C++-like debuginfo are affected -- which currently is only `*-pc-windows-msvc`.

*TODO*
- [x] Properly update documentation
- [x] Add regression tests for new optimized enum layouts as introduced by .

r? `@wesleywiser`
2022-08-15 12:59:53 +00:00
Josh Stone
2970ad8aee Update the minimum external LLVM to 13 2022-08-14 13:46:51 -07:00
Mark Rousskov
154a09dd91 Adjust cfgs 2022-08-12 16:28:15 -04:00
ridwanabdillahi
804579ca77 Respond to RFC comments. 2022-08-12 11:34:31 -07:00
Michael Woerister
b0e3ed6e8d [debuginfo] Use IndexMap instead of FxHashMap while generating cpp-like generator debuginfo. 2022-08-12 10:53:08 +02:00
Michael Woerister
95d7591478 [debuginfo] Update cpp-like enum decoding docs to account for wrapping tag ranges. 2022-08-12 10:53:08 +02:00
Michael Woerister
171d8a3f57 [debuginfo] Don't mark fields and types as artificial in CPP-like enum debuginfo encoding.
LLDB historically has had problems with "artificial" entries and there
is no real benefit to emitting that flag.
2022-08-12 10:53:08 +02:00
Michael Woerister
8433e2a66f [debuginfo] Remove the notion of a 'fallback variant' from the CPP-like enum debuginfo encoding. 2022-08-12 10:53:08 +02:00
Michael Woerister
063ebfa570 Use enum2<_> instead of enum<_> for Cpp-like debuginfo enum type names.
And add more comments about niche tag enum encoding.
2022-08-12 10:53:07 +02:00
Michael Woerister
622da5d834 debuginfo: Change C++-like encoding for enums.
The updated encoding should be able to handle niche layouts where
more than one variant has fields.
2022-08-12 10:53:07 +02:00
ridwanabdillahi
100882296e Add support for generating unique *.profraw files by default when using the -C instrument-coverage flag.
Respond to PR comments.
2022-08-11 16:04:08 -07:00
Nikita Popov
89582e8193 Pass +atomics-32 feature for thumbv6m target
https://reviews.llvm.org/D120026 changed atomics on thumbv6m to
use libatomic, to ensure that atomic load/store are compatible with
atomic RMW/CAS. However, Rust wants to expose only load/store
without libcalls.

https://reviews.llvm.org/D130480 added support for this behind
the +atomics-32 target feature, so enable that feature.
2022-08-09 12:39:59 +02:00
Dylan DPC
1d010d4382
Rollup merge of - bjorn3:archive_builder_interface_refactor, r=nagisa
Introduce an ArchiveBuilderBuilder

This avoids monomorphizing all linker code for each codegen backend and will allow passing in extra information to the archive builder from the codegen backend. I'm going to use this in https://github.com/rust-lang/rust/pull/97485 to allow passing in the right function to extract symbols from object files to a generic archive builder to be used by cg_llvm, cg_clif and cg_gcc.
2022-07-31 17:36:42 +05:30
bjorn3
7c6c7e8785 Introduce an ArchiveBuilderBuilder
This avoids monomorphizing all linker code for each codegen backend and
will allow passing in extra information to the archive builder from the
codegen backend.
2022-07-28 09:08:47 +00:00
bjorn3
90da3c6f2b Inline inject_dll_import_lib 2022-07-28 08:43:15 +00:00
bjorn3
7c93154a30 Move output argument from ArchiveBuilder::new to .build() 2022-07-28 08:39:19 +00:00
Nikita Popov
f653d3ab30 Add elementtype attributes for llvm.arm.ldrex/strex intrinsics
These intrinsics (and a few more, but there are the only ones
exposed by stdarch) require an elementtype attribute in LLVM 15.
2022-07-27 16:19:07 +02:00
Yuki Okushi
7f608e99dc
Rollup merge of - bjorn3:remove_llvm_dead_code, r=nikic
Remove dead code from cg_llvm

Found while working on https://github.com/rust-lang/rust/pull/97485
2022-07-27 11:52:56 +09:00
bors
4d6d601c8a Auto merge of - durin42:allocator-patch-redux, r=nikic
codegen: use new {re,de,}allocator annotations in llvm

This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.

The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.

r? `@nikic`
2022-07-26 19:35:57 +00:00
Augie Fackler
130a1df71e codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.

The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.

While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes . [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.

The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
2022-07-26 09:43:28 -04:00
bjorn3
017e1726ff Remove dead code from cg_llvm 2022-07-26 11:29:18 +00:00
bors
daaae25022 Auto merge of - dpaoliello:rawdylibbin, r=michaelwoerister
Enable raw-dylib for bin crates

Fixes 

When `raw-dylib` is used in a `bin` crate, we need to collect all of the `raw-dylib` functions, generate the import library and add that to the linker command line.

I also changed the tests so that 1) the C++ dlls are created after the Rust dlls, thus there is no chance of accidentally using them in the Rust linking process and 2) disabled generating import libraries when building with MSVC.
2022-07-26 01:47:34 +00:00
bors
db8086eb60 Auto merge of - rcvalle:rust-cfi-2, r=nagisa
Add fine-grained LLVM CFI support to the Rust compiler

This PR improves the LLVM Control Flow Integrity (CFI) support in the Rust compiler by providing forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types.

Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue https://github.com/rust-lang/rust/issues/89653).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).

Thank you again, `@eddyb,` `@nagisa,` `@pcc,` and `@tmiasko` for all the help!
2022-07-24 01:22:36 +00:00
bors
93ffde6f04 Auto merge of - ivanloz:master, r=nagisa
Add support for LLVM ShadowCallStack.

LLVMs ShadowCallStack provides backward edge control flow integrity protection by using a separate shadow stack to store and retrieve a function's return address.

LLVM currently only supports this for AArch64 targets. The x18 register is used to hold the pointer to the shadow stack, and therefore this only works on ABIs which reserve x18. Further details are available in the [LLVM ShadowCallStack](https://clang.llvm.org/docs/ShadowCallStack.html) docs.

# Usage
`-Zsanitizer=shadow-call-stack`

# Comments/Caveats
* Currently only enabled for the aarch64-linux-android target
* Requires the platform to define a runtime to initialize the shadow stack, see the [LLVM docs](https://clang.llvm.org/docs/ShadowCallStack.html) for more detail.
2022-07-23 20:01:07 +00:00
Ramon de C Valle
5ad7a646a5 Add fine-grained LLVM CFI support to the Rust compiler
This commit improves the LLVM Control Flow Integrity (CFI) support in
the Rust compiler by providing forward-edge control flow protection for
Rust-compiled code only by aggregating function pointers in groups
identified by their return and parameter types.

Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue ).

LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e.,
-Clto).
2022-07-23 10:51:34 -07:00
Daniel Paoliello
1f33785ed4 Enable raw-dylib for binaries 2022-07-22 09:55:14 -07:00
bors
aa01891700 Auto merge of - RalfJung:vtable, r=oli-obk
make vtable pointers entirely opaque

This implements the scheme discussed in https://github.com/rust-lang/unsafe-code-guidelines/issues/338: vtable pointers should be considered entirely opaque and not even readable by Rust code, similar to function pointers.

- We have a new kind of `GlobalAlloc` that symbolically refers to a vtable.
- Miri uses that kind of allocation when generating a vtable.
- The codegen backends, upon encountering such an allocation, call `vtable_allocation` to obtain an actually dataful allocation for this vtable.
- We need new intrinsics to obtain the size and align from a vtable (for some `ptr::metadata` APIs), since direct accesses are UB now.

I had to touch quite a bit of code that I am not very familiar with, so some of this might not make much sense...
r? `@oli-obk`
2022-07-22 01:33:49 +00:00
bors
74f600b990 Auto merge of - nextsilicon:support_lto_embed_bitcode, r=davidtwco
Allow to disable thinLTO buffer to support lto-embed-bitcode lld feature

Hello
This change is to fix issue (https://github.com/rust-lang/rust/issues/84395) in which passing "-lto-embed-bitcode=optimized" to lld when linking rust code via linker-plugin-lto doesn't produce the expected result.

Instead of emitting a single unified module into a llvmbc section of the linked elf, it emits multiple submodules.
This is caused because rustc emits the BC modules after running llvm `createWriteThinLTOBitcodePass` pass.
Which in turn triggers a thinLTO linkage and causes the said issue.

This patch allows via compiler flag (-Cemit-thin-lto=<bool>) to select between running `createWriteThinLTOBitcodePass` and `createBitcodeWriterPass`.
Note this pattern of selecting between those 2 passes is common inside of LLVM code.
The default is to match the old behavior.
2022-07-21 10:13:59 +00:00
bors
ceeb5ade20 Auto merge of - thomcc:used-macho, r=pnkfelix
Only compile #[used] as llvm.compiler.used for ELF targets

This returns `#[used]` to how it worked prior to the LLVM 13 update. The intention is not that this is a stable promise.

I'll add tests later today. The tests will test things that we don't actually promise, though.

It's a deliberately small patch, mostly comments. And assuming it's reviewed and lands in time, IMO it should at least be considered for uplifting to beta (so that it can be in 1.59), as the change broke many crates in the ecosystem, even if they are relying on behavior that is not guaranteed.

# Background

LLVM has two ways of preventing removal of an unused variable: `llvm.compiler.used`, which must be present in object files, but allows the linker to remove the value, and `llvm.used` which is supposed to apply to the linker as well, if possible.

Prior to LLVM 13, `llvm.used` and `llvm.compiler.used` were the same on ELF targets, although they were different elsewhere. Prior to our update to LLVM 13, we compiled `#[used]` using `llvm.used` unconditionally, even though we only ever promised behavior like `llvm.compiler.used`.

In LLVM 13, ELF targets gained some support for preventing linker removal of `llvm.used` via the SHF_RETAIN section flag. This has some compatibility issues though: Concretely: some older versions `ld.gold` (specifically ones prior to v2.36, released in Jan 2021) had a bug where it would fail to place a `#[used] #[link_section = ".init_array"]` static in between `__init_array_start`/`__init_array_end`, leading to code that does this failing to run a static constructor. This is technically not a thing we guarantee will work, is a common use case, and is needed in `libstd` (for example, to get access to `std::env::args()` even if Rust does not control `main`, such as when in a `cdylib` crate).

As a result, when updating to LLVM 13, we unconditionally switched to using `llvm.compiler.used`, which mirror the guarantees we make for `#[used]` and doesn't require the latest ld.gold. Unfortunately, this happened to break quite a bit of things in the ecosystem, as non-ELF targets had come to rely on `#[used]` being slightly stronger. In particular, there are cases where it will even break static constructors on these targets[^initinit] (and in fact, breaks way more use cases, as Mach-O uses special sections as an interface to the OS/linker/loader in many places).

As a result, we only switch to `llvm.compiler.used` on ELF[^elfish] targets. The rationale here is:

1. It is (hopefully) identical to the semantics we used prior to the LLVM13 update as prior to that update we unconditionally used `llvm.used`, but on ELF `llvm.used` was the same as `llvm.compiler.used`.

2. It seems to be how Clang compiles this, and given that they have similar (but stronger) compatibility promises, that makes sense.

[^initinit]: For Mach-O targets: It is not always guaranteed that `__DATA,__mod_init_func` is a GC root if it does not have the `S_MOD_INIT_FUNC_POINTERS` flag which we cannot add. In most cases, when ld64 transformed this section into `__DATA_CONST,__mod_init_func` it gets applied, but it's not clear that that is intentional (let alone guaranteed), and the logic is complex enough that it probably happens sometimes, and people in the wild report it occurring.

[^elfish]: Actually, there's not a great way to tell if it's ELF, so I've approximated it.

This is pretty ad-hoc and hacky! We probably should have a firmer set of guarantees here, but this change should relax the pressure on coming up with that considerably, returning it to previous levels.

---

Unsure who should review so leaving it open, but for sure CC `@nikic`
2022-07-21 06:59:32 +00:00
bjorn3
399e020b96 Move vtable_size and vtable_align impls to cg_ssa 2022-07-20 17:12:08 -04:00
Ralf Jung
adf6d37d83 slightly cleaner, if more verbose, vtable handling in codegen backends 2022-07-20 17:12:07 -04:00
Ralf Jung
3dad266f40 consistently use VTable over Vtable (matching stable stdlib API RawWakerVTable) 2022-07-20 17:12:07 -04:00
Ralf Jung
5e840c5c8c incorporate some review feedback 2022-07-20 17:12:07 -04:00
Ralf Jung
8affef2ccb add intrinsic to access vtable size and align 2022-07-20 17:12:07 -04:00
Ralf Jung
da5e4d73f1 add a Vtable kind of symbolic allocations 2022-07-20 16:57:31 -04:00
Ivan Lozano
adf61e3b2b Add ShadowCallStack Support
Adds support for the LLVM ShadowCallStack sanitizer.
2022-07-20 13:43:34 +00:00
Matthias Krüger
4815f94c51
Rollup merge of - TaKO8Ki:avoid-symbol-to-&str-conversions, r=nnethercote
Avoid `Symbol` to `&str` conversions

`Symbol::as_str` is a slowish operation, so this patch removes some usages of it.
2022-07-19 13:30:46 +02:00
Dylan DPC
a027b01f33
Rollup merge of - workingjubilee:naked-means-no-clothes-enforcement-technology, r=Amanieu
Remove branch target prologues from `#[naked] fn`

This patch hacks around  for now via injecting appropriate attributes into the LLVMIR we emit for naked functions. I intend to pursue this upstream so that these attributes can be removed in general, but it's slow going wading through C++ for me.
2022-07-18 21:14:43 +05:30
Takayuki Maeda
a22934bea1 avoid Symbol to &str conversions 2022-07-18 14:25:34 +09:00
Caio
3266460749 Stabilize let_chains 2022-07-16 20:17:58 -03:00
bors
e6c43cf8b9 Auto merge of - oxidecomputer:restore-static-dwarf, r=pnkfelix
Revert "Work around invalid DWARF bugs for fat LTO"

Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See  for more info
and a repro case.

This commit is a mechanical revert of
d5de680e20 from PR , which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)

I have locally verified that this fixes  by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
2022-07-16 00:18:54 +00:00
Ziv Dunkelman
724c91234d rustc: add ability to output regular LTO bitcode modules
Adding the option to control from rustc CLI
if the resulted ".o" bitcode module files are with
thinLTO info or regular LTO info.

Allows using "-lto-embed-bitcode=optimized" during linkage
correctly.

Signed-off-by: Ziv Dunkelman <ziv.dunkelman@nextsilicon.com>
2022-07-14 22:21:26 +03:00
Rémy Rakic
97510f2128 fix dwarf debuginfo being used in addition to CodeView on windows
Fixes the debuginfo size increase regression introduced by the DWARF5 support.
2022-07-14 20:41:55 +02:00
Joshua Nelson
3c9765cff1 Rename debugging_opts to unstable_opts
This is no longer used only for debugging options (e.g. `-Zoutput-width`, `-Zallow-features`).
Rename it to be more clear.
2022-07-13 17:47:06 -05:00
Dylan DPC
68cfdbb5c1
Rollup merge of - Amanieu:unstable-target-features, r=davidtwco
Keep unstable target features for asm feature checking

Inline assembly uses the target features to determine which registers
are available on the current target. However it needs to be able to
access unstable target features for this.

Fixes 
2022-07-13 19:32:36 +05:30
Amanieu d'Antras
e51f1b7e27 Keep unstable target features for asm feature checking
Inline assembly uses the target features to determine which registers
are available on the current target. However it needs to be able to
access unstable target features for this.

Fixes 
2022-07-11 14:26:58 +01:00
Ralf Jung
a422b42159 don't allow ZST in ScalarInt
There are several indications that we should not ZST as a ScalarInt:
- We had two ways to have ZST valtrees, either an empty `Branch` or a `Leaf` with a ZST in it.
  `ValTree::zst()` used the former, but the latter could possibly arise as well.
- Likewise, the interpreter had `Immediate::Uninit` and `Immediate::Scalar(Scalar::ZST)`.
- LLVM codegen already had to special-case ZST ScalarInt.

So instead add new ZST variants to those types that did not have other variants
which could be used for this purpose.
2022-07-09 07:27:29 -04:00