Fix thumbv4t-none-eabi frame pointer setting
The `thumb_base` profile has changed since I last remember seeing it, and now it sets the frame pointer to "always keep", which is not desired for this target. Hooking a debugger to the running program is not really done, it's preferable to have the register available for actual program use, so the default "may omit" is now set.
I thought that the target was already using "may omit" when I checked on it last month, because I forgot that the target was previously based on `thumb_base` rather than `Default::default()`. I only noticed the issue just now when creating the `armv4t-none-eabi` target (https://github.com/rust-lang/rust/pull/99226), though this PR is not in any way conditional on that one.
Rollup of 6 pull requests
Successful merges:
- #99298 (Make `ui-fulldeps/gated-plugins` and `ui-fulldeps/multiple-plugins` tests stage 2 only)
- #99396 (Add some additional double-adjustment regression tests)
- #99449 (Do not resolve associated const when there is no provided value)
- #99595 (Mark atomics as unsupported on thumbv6m)
- #99627 (Lock stdout once when listing tests)
- #99638 (Remove Clean trait implementation for hir::Ty and middle::Ty)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Mark atomics as unsupported on thumbv6m
The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.
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.
The thumbv6m target does not support atomics. Historically, LLVM
had a bug where atomic load/stores for this target were emitted
as plain load/stores rather than as libatomic calls. This was
fixed in https://reviews.llvm.org/D120026, which will be part of
LLVM 15. As we require that "atomic support" does not use libatomic,
we need to indicate that this target does not have native atomics.
Use constant eval to do strict mem::uninit/zeroed validity checks
I'm not sure about the code organisation here, I just dumped the check in rustc_const_eval at the root. Not hard to move it elsewhere, in any case.
Also, this means cranelift codegen intrinsics lose the strict checks, since they don't seem to depend on rustc_const_eval, and I didn't see a point in keeping around two copies.
I also left comments in the is_zero_valid methods about "uhhh help how do i do this", those apply to both methods equally.
Also rustc_codegen_ssa now depends on rustc_const_eval... is this okay?
Pinging `@RalfJung` since you were the one who mentioned this to me, so I'm assuming you're interested.
Haven't had a chance to run full tests on this since it's really warm, and it's 1AM, I'll check out any failures/comments in the morning :)
DWARF version 5 brings a number of improvements over version 4. Quoting from
the announcement [1]:
> Version 5 incorporates improvements in many areas: better data compression,
> separation of debugging data from executable files, improved description of
> macros and source files, faster searching for symbols, improved debugging
> optimized code, as well as numerous improvements in functionality and
> performance.
On platforms where DWARF version 5 is supported (Linux, primarily), this commit
adds support for it behind a new `-Z dwarf-version=5` flag.
[1]: https://dwarfstd.org/Public_Review.php
rustc_target: Remove some redundant target properties
`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.
`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.
I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
Make debug_triple depend on target json file content rather than file path
This ensures that changes to target json files will force a recompilation. And more importantly that moving the files doesn't force a recompilation.
This should fix https://github.com/Rust-for-Linux/linux/issues/792 (cc ``@ojeda)``
Removes debug settings from wasm32_unknown_emscripten default link args
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
``@sbc100``
This is a debug setting. We should only make debug builds if user requests
a debug build. Currently this is inserted in release builds.
Furthermore, it would be better to insert these settings in --pre-link-args
because then it would be possible to override them if appropriate. Because
these are inserted at the end, it is necessary to patch emscripten to remove
them.
Relax mipsel-sony-psp's linker script
Previously, the linker script forcefully kept all `.lib.stub` sections, unnecessarily bloating the binary. Now, the script is LTO and `--gc-sections` friendly.
`--nmagic` was also added to the linker, because page alignment is not required on the PSP. This further reduces binary size.
Accompanying changes for the `psp` crate are found in: https://github.com/overdrivenpotato/rust-psp/pull/118
Previously, the linker script forcefully kept all `.lib.stub` sections,
unnecessarily bloating the binary. Now, the script is LTO and
`--gc-sections` friendly.
`--nmagic` was also added to the linker, because page alignment is not
required on the PSP. This further reduces binary size.
Accompanying changes for the PSP crate are found in:
https://github.com/overdrivenpotato/rust-psp/pull/118
Add support for emitting functions with `coldcc` to LLVM
The eventual goal is to try using this for things like the internal panicking stuff, to see whether it helps.
