| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Create more accurate debuginfo for vtables.
Before this PR all vtables would have the same name (`"vtable"`) in debuginfo. Now they get an unambiguous name that identifies the implementing type and the trait that is being implemented.
This is only one of several possible improvements:
- This PR describes vtables as arrays of `*const u8` pointers. It would nice to describe them as structs where function pointer is represented by a field with a name indicative of the method it maps to. However, this requires coming up with a naming scheme that avoids clashes between methods with the same name (which is possible if the vtable contains multiple traits).
- The PR does not update the debuginfo we generate for the vtable-pointer field in a fat `dyn` pointer. Right now there does not seem to be an easy way of getting ahold of a vtable-layout without also knowing the concrete self-type of a trait object.
r? `@wesleywiser`
|
|
Before this commit all vtables would have the same name "vtable" in
debuginfo. Now they get a name that identifies the implementing type
and the trait that is being implemented.
|
|
|
|
Add `pie` as another `relocation-model` value
MCP: https://github.com/rust-lang/compiler-team/issues/461
|
|
|
|
|
|
Check whether a call/invoke of the function exists, but don't
match a leftover function declaration.
Also remove the CHECK-LABELs: In panic-in-drop=unwind mode the
call will not actually be in either of those functions, so
remove the restriction and look for any calls.
|
|
This fixes compiling things like the `snap` crate after
https://reviews.llvm.org/D105462. I added a test that verifies the
additional attribute gets specified, and confirmed that I can build
cargo with both LLVM 13 and 14 with this change applied.
|
|
|
|
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC
Fixes #88315
|
|
Fixes #88315
|
|
|
|
|
|
Add needs-asm-support to more tests
These were found as test failures on s390x for RHEL and Fedora.
|
|
These were found as test failures on s390x for RHEL and Fedora.
|
|
This has regressed due to https://bugs.llvm.org/show_bug.cgi?id=51211.
It's pretty likely that we'll have to eat this regression for this
release.
|
|
|
|
Fix `reachable_set` for non-function items in non-library crates
I unintentionally changed `reachable_set` to ignore non-function items when `!self.any_library` in https://github.com/rust-lang/rust/pull/86492, which can lead to "undefined reference" errors in non-library (`cdylib`/`staticlib`/`bin`) crates, for example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=6bb2c5065a9be7e40943d0541e161b5a
This PR restores the behavior of `reachable_set` for non-function items.
Fixes https://github.com/rust-lang/rust/issues/88016.
<details>
<summary>The modified test will fail with this output without the `reachable_set` change</summary>
```
---- [codegen] codegen/external-no-mangle-statics.rs#staticlib stdout ----
error in revision `staticlib`: verification with 'FileCheck' failed
status: exit status: 1
command: "/checkout/build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck" "--input-file" "/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll" "/checkout/src/test/codegen/external-no-mangle-statics.rs" "--check-prefixes" "CHECK,NONMSVC,staticlib"
stdout:
------------------------------------------
------------------------------------------
stderr:
------------------------------------------
/checkout/src/test/codegen/external-no-mangle-statics.rs:10:11: error: CHECK: expected string not found in input
// CHECK: `@A` = local_unnamed_addr constant
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:1: note: scanning from here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
/checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll:1:6: note: possible intended match here
; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
^
Input file: /checkout/build/x86_64-unknown-linux-gnu/test/codegen/external-no-mangle-statics.staticlib/external-no-mangle-statics.ll
Check file: /checkout/src/test/codegen/external-no-mangle-statics.rs
-dump-input=help explains the following input dump.
Input was:
<<<<<<
1: ; ModuleID = 'external_no_mangle_statics.b50529d3-cgu.0'
check:10'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
check:10'1 ? possible intended match
2: source_filename = "external_no_mangle_statics.b50529d3-cgu.0"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
4: target triple = "x86_64-unknown-linux-gnu"
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5:
check:10'0 ~
6: !llvm.module.flags = !{!0, !1}
check:10'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
.
.
.
>>>>>>
------------------------------------------
failures:
[codegen] codegen/external-no-mangle-statics.rs#staticlib
```
</details>
|
|
Add support for clobber_abi to asm!
This PR adds the `clobber_abi` feature that was proposed in #81092.
Fixes #81092
cc `@rust-lang/wg-inline-asm`
r? `@nagisa`
|
|
|
|
Lint against named asm labels
This adds a deny-by-default lint to prevent the use of named labels in inline `asm!`. Without a solution to #81088 about whether the compiler should rewrite named labels or a special syntax for labels, a lint against them should prevent users from writing assembly that could break for internal compiler reasons, such as inlining or anything else that could change the number of actual inline assembly blocks emitted.
This does **not** resolve the issue with rewriting labels, that still needs a decision if the compiler should do any more work to try to make them work.
|
|
|
|
rusticstuff:rustc_codegen_llvm_dont_emit_zero_sized_padding, r=eddyb
LLVM codegen: Don't emit zero-sized padding for fields
Currently padding is emitted before fields of a struct and at the end of the struct regardless of the ABI. Even if no padding is required zero-sized padding fields are emitted. This is not useful and - more importantly - it make it impossible to generate the exact vector types that LLVM expects for certain ARM SIMD intrinsics. This change should unblock the implementation of many ARM intrinsics using the `unadjusted` ABI, see https://github.com/rust-lang/stdarch/issues/1143#issuecomment-827404092.
This is a proof of concept only because the field lookup now takes O(number of fields) time compared to O(1) before since it recalculates the mapping at every lookup. I would like to find out how big the performance impact actually is before implementing caching or restricting this behavior to the `unadjusted` ABI.
cc `@SparrowLii` `@bjorn3`
([Discussion on internals](https://internals.rust-lang.org/t/feature-request-add-a-way-in-rustc-for-generating-struct-type-llvm-ir-without-paddings/15007))
|
|
Avoid using the `copy_nonoverlapping` wrapper through `mem::replace`.
This is a much simpler way to achieve the pre-#86003 behavior of `mem::replace` not needing dynamically-sized `memcpy`s (at least before inlining), than re-doing #81238 (which needs #86699 or something similar).
I didn't notice it until recently, but `ptr::write` already explicitly avoided using the wrapper, while `ptr::read` just called the wrapper (and was the reason for us observing any behavior change from #86003 in Rust-GPU).
<hr/>
The codegen test I've added fails without the change to `core::ptr::read` like this (ignore the `v0` mangling, I was using a worktree with it turned on by default, for this):
```llvm
13: ; core::intrinsics::copy_nonoverlapping::<u8>
14: ; Function Attrs: inlinehint nonlazybind uwtable
15: define internal void `@_RINvNtCscK5tvALCJol_4core10intrinsics19copy_nonoverlappinghECsaS4X3EinRE8_25mem_replace_direct_memcpy(i8*` %src, i8* %dst, i64 %count) unnamed_addr #0 {
16: start:
17: %0 = mul i64 %count, 1
18: call void `@llvm.memcpy.p0i8.p0i8.i64(i8*` align 1 %dst, i8* align 1 %src, i64 %0, i1 false)
not:17 !~~~~~~~~~~~~~~~~~~~~~ error: no match expected
19: ret void
20: }
```
With the `core::ptr::read` change, `core::intrinsics::copy_nonoverlapping` doesn't get instantiated and the test passes.
<hr/>
r? `@m-ou-se` cc `@nagisa` (codegen test) `@oli-obk` / `@RalfJung` (miri diagnostic changes)
|
|
|
|
The v0 mangling includes an instantiating crate in a mangled name,
which crates a false positive match for a word `panic`.
Rename crate name / test case to avoid the issue.
|
|
Testcase to make sure that no 0-sized padding is inserted in structs and that structs are represented as expected by Neon intrinsics in LLVM.
|
|
|
|
|
|
nounwind is no longer emitted but the test still passes
|
|
This commit intends to fill out some of the remaining pieces of the
C-unwind ABI. This has a number of other changes with it though to move
this design space forward a bit. Notably contained within here is:
* On `panic=unwind`, the `extern "C"` ABI is now considered as "may
unwind". This fixes a longstanding soundness issue where if you
`panic!()` in an `extern "C"` function defined in Rust that's actually
UB because the LLVM representation for the function has the `nounwind`
attribute, but then you unwind.
* Whether or not a function unwinds now mainly considers the ABI of the
function instead of first checking the panic strategy. This fixes a
miscompile of `extern "C-unwind"` with `panic=abort` because that ABI
can still unwind.
* The aborting stub for non-unwinding ABIs with `panic=unwind` has been
reimplemented. Previously this was done as a small tweak during MIR
generation, but this has been moved to a separate and dedicated MIR
pass. This new pass will, for appropriate functions and function
calls, insert a `cleanup` landing pad for any function call that may
unwind within a function that is itself not allowed to unwind. Note
that this subtly changes some behavior from before where previously on
an unwind which was caught-to-abort it would run active destructors in
the function, and now it simply immediately aborts the process.
* The `#[unwind]` attribute has been removed and all users in tests and
such are now using `C-unwind` and `#![feature(c_unwind)]`.
I think this is largely the last piece of the RFC to implement.
Unfortunately I believe this is still not stabilizable as-is because
activating the feature gate changes the behavior of the existing `extern
"C"` ABI in a way that has no replacement. My thinking for how to enable
this is that we add support for the `C-unwind` ABI on stable Rust first,
and then after it hits stable we change the behavior of the `C` ABI.
That way anyone straddling stable/beta/nightly can switch to `C-unwind`
safely.
|
|
MSVC.
The LLVM limitation that previously prevented this has been fixed in LLVM
9 which is older than the oldest LLVM version we currently support.
See https://github.com/rust-lang/rust/issues/61002.
|
|
|
|
Add clobber-only register classes for asm!
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
|
|
These are needed to properly express a function call ABI using a clobber
list, even though we don't support passing actual values into/out of
these registers.
|
|
|
|
Showing that this avoids an alloca and private constant.
|
|
|
|
[msvc] Consistently show active variant and fix visualization for single variant enums
Prior to this change, there were a few cases where inspecting an enum in either WinDbg or Visual Studio would not show the active variant name. After these changes, we now consistently show the active variant name as `[variant]` in the debugger.
We also didn't handle single variant enums very well. That is now also resolved.
Before:
After:
r? `@michaelwoerister`
|
|
It makes very little sense to maintain denylists of ABIs when, as far as
non-generic ABIs are concerned, targets usually only support a small
subset of the available ABIs.
This has historically been a cause of bugs such as us allowing use of
the platform-specific ABIs on x86 targets – these in turn would cause
LLVM errors or assertions to fire.
Fixes #57182
Sponsored by: standard.ai
|
|
|
|
Improve debug symbol names to avoid ambiguity and work better with MSVC's debugger
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
|
|
debugger
There are several cases where names of types and functions in the debug info are either ambiguous, or not helpful, such as including ambiguous placeholders (e.g., `{{impl}}`, `{{closure}}` or `dyn _'`) or dropping qualifications (e.g., for dynamic types).
Instead, each debug symbol name should be unique and useful:
* Include disambiguators for anonymous `DefPathDataName` (closures and generators), and unify their formatting when used as a path-qualifier vs item being qualified.
* Qualify the principal trait for dynamic types.
* If there is no principal trait for a dynamic type, emit all other traits instead.
* Respect the `qualified` argument when emitting ref and pointer types.
* For implementations, emit the disambiguator.
* Print const generics when emitting generic parameters or arguments.
Additionally, when targeting MSVC, its debugger treats many command arguments as C++ expressions, even when the argument is defined to be a symbol name. As such names in the debug info need to be more C++-like to be parsed correctly:
* Avoid characters with special meaning (`#`, `[`, `"`, `+`).
* Never start a name with `<` or `{` as this is treated as an operator.
* `>>` is always treated as a right-shift, even when parsing generic arguments (so add a space to avoid this).
* Emit function declarations using C/C++ style syntax (e.g., leading return type).
* Emit arrays as a synthetic `array$<type, size>` type.
* Include a `$` in all synthetic types as this is a legal character for C++, but not Rust (thus we avoid collisions with user types).
|
|
This PR adds ability for the target specifications to specify frame
pointer emission type that's not just “always” or “whatever cg decides”.
In particular there's a new mode that allows omission of the frame
pointer for leaf functions (those that don't call any other functions).
We then set this new mode for Aarch64-based Apple targets.
Fixes #86196
|
|
Add a "raw" option for asm! which ignores format string specifiers
This is useful when including raw assembly snippets using `include_str!`.
|
|
|
|
Doesn't work though, because compiletest doesn't process ignores on a
per-revision manner.
|
|
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
|
|
|
|
|
