| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Generate an iOS LLVM target with a specific version
This commit adds the `LC_VERSION_MIN_IPHONEOS` load command to the Mach-O header generated for `aarch64-apple-ios` binaries. The operating system will look for this load command to determine the minimum supported operating system version and will not allow the binary to run if it's absent. This logic already exists for the simulator toolchain.
I've been using `otool` from a [cctools](https://github.com/tpoechtrager/cctools-port) toolchain to parse the header and validate that this change adds the required load command.
This change appears to be enough to build Rust binaries that can run on a jailbroken iPhone.
|
|
|
|
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 https://github.com/llvm/llvm-project/commit/1558bb80c01b695ce12642527cbfccf16cf54ece.
* ~~https://bugs.llvm.org/show_bug.cgi?id=51476 (Miscompile on AArch64 due to incorrect comparison elimination)~~ Fixed by https://github.com/llvm/llvm-project/commit/81b106584f2baf33e09be2362c35c1bf2f6bfe94.
* 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`
|
|
freebsd arm64 add supported sanitizers.
|
|
|
|
|
|
Without the specific version, the mach-o header will be missing the
minimum supported operating system version. This is mandatory for
running Rust binaries on iOS devices.
|
|
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`
|
|
|
|
Add c_enum_min_bits target spec field, use for arm-none and thumb-none targets
Fixes https://github.com/rust-lang/rust/issues/87917
<s>Haven't tested this yet, still playing around.</s>
This seems to fix the issue.
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Add `aarch64-unknown-uefi` target
This pull request adds the `aarch64-unknown-uefi` target.
|
|
* This commit adds the aarch64-unknown-uefi target and also adds it into
the supported targets list under the tier-3 target table.
* Uses the small code model by default
Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
|
|
netbsd x86_64 arch enable supported sanitizers.
|
|
more clippy::complexity fixes
(also a couple of clippy::perf fixes)
|
|
|
|
related issue #43575
|
|
|
|
|
|
r=petrochenkov
Use small code model for UEFI targets
* Since the code model only applies to the code and not the data and the code model
only applies to functions you call through using `call`, `jmp` and data with `lea`, etc…
If you are calling functions using the function pointers from the UEFI structures the code
model does not apply in that case. It’s just related to the address space size of your own binary.
Since UEFI (uefi is all relocatable) uses relocatable PEs (relocatable code does not care about the
code model) so, we use the small code model here.
* Since applications don't usually take gigabytes of memory, setting the
target to use the small code model should result in better codegen (comparable
with majority of other targets).
Large code models are also known for generating horrible code, for
example 16 bytes of code to load a single 8-byte value.
Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
|
|
Do not allow JSON targets to set is-builtin: true
Note that this will affect (and make builds fail for) all of the projects out there that have target files invalid in this way. Crater, however, does not really cover these kinds of the codebases, so it is quite difficult to measure the impact. That said, the target files invalid in this way can start causing build failures each time LLVM is upgraded, anyway, so it is probably a good opportunity to disallow this property, entirely.
Another approach considered was to simply not parse this field anymore, which would avoid making the builds explicitly fail, but it wasn't clear to me if `is-builtin` was always set unintentionally… In case this was the case, I'd expect people to file a feature request stating specifically for what purpose they were using `is-builtin`.
Fixes #86017
|
|
* Since the code model only applies to the code and not the data and the code model
only applies to functions you call through using `call`, `jmp` and data with `lea`, etc…
If you are calling functions using the function pointers from the UEFI structures the code
model does not apply in that case. It’s just related to the address space size of your own binary.
Since UEFI (uefi is all relocatable) uses relocatable PEs (relocatable code does not care about the
code model) so, we use the small code model here.
* Since applications don't usually take gigabytes of memory, setting the
target to use the small code model should result in better codegen (comparable
with majority of other targets).
Large code models are also known for generating horrible code, for
example 16 bytes of code to load a single 8-byte value.
* Use the LLVM default code model for the architecture for the
x86_64-unknown-uefi targets. For reference small is the default
code model on x86 in LLVM: <https://github.com/llvm/llvm-project/blob/7de2173c2a4c45711831cfee3ccf53690c76ff07/llvm/lib/Target/X86/X86TargetMachine.cpp#L204>
* Remove the comments too as they are not UEFI-specific and applies
to pretty much any target. I added them before as I was explicitily
setting the code model to small.
Signed-off-by: Andy-Python-Programmer <andypythonappdeveloper@gmail.com>
|
|
target abi
Implement cfg(target_abi) (RFC 2992)
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
Update targets to use `target_abi`
All eabi targets have `target_abi = "eabi".`
All eabihf targets have `target_abi = "eabihf"`.
`armv6_unknown_freebsd` and `armv7_unknown_freebsd` have `target_abi = "eabihf"`.
All abi64 targets have `target_abi = "abi64"`.
All ilp32 targets have `target_abi = "ilp32"`.
All softfloat targets have `target_abi = "softfloat"`.
All *-uwp-windows-* targets have `target_abi = "uwp"`.
All spe targets have `target_abi = "spe"`.
All macabi targets have `target_abi = "macabi"`.
aarch64-apple-ios-sim has `target_abi = "sim"`.
`x86_64-fortanix-unknown-sgx` has `target_abi = "fortanix"`.
`x86_64-unknown-linux-gnux32` has `target_abi = "x32"`.
Add FIXME entries for targets for which existing values need to change
once `cfg_target_abi` becomes stable. (All of them are tier 3 targets.)
Add a test for `target_abi` in `--print cfg`.
|
|
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.
|
|
|
|
All eabi targets have target_abi = "eabi".
All eabihf targets have target_abi = "eabihf".
armv6_unknown_freebsd and armv7_unknown_freebsd have target_abi = "eabihf".
All abi64 targets have target_abi = "abi64".
All ilp32 targets have target_abi = "ilp32".
All softfloat targets have target_abi = "softfloat".
All *-uwp-windows-* targets have target_abi = "uwp".
All spe targets have target_abi = "spe".
All macabi targets have target_abi = "macabi".
aarch64-apple-ios-sim has target_abi = "sim".
x86_64-fortanix-unknown-sgx has target_abi = "fortanix".
x86_64-unknown-linux-gnux32 has target_abi = "x32".
Add FIXME entries for targets for which existing values need to change
once cfg_target_abi becomes stable. (All of them are tier 3 targets.)
Add a test for target_abi in `--print cfg`.
|
|
Add an `abi` field to `TargetOptions`, defaulting to "". Support using
`cfg(target_abi = "...")` for conditional compilation on that field.
Gated by `feature(cfg_target_abi)`.
Add a test for `target_abi`, and a test for the feature gate.
Add `target_abi` to tidy as a platform-specific cfg.
This does not add an abi to any existing target.
|
|
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
|
|
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
|
|
|
|
|
|
Emit warnings for unused fields in custom targets.
Add a warning which lists any fields in a custom target `json` file that aren't used. Currently unrecognized fields are ignored so, for example, a typo in the `json` will silently produce a target which isn't the one intended.
|
|
|
|
Add support for powerpc64le-unknown-freebsd
|
|
|
|
|
|
Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.
Reported via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/wasi.20linker.20unknown.20argument.3A.20--as-needed): we try passing `--as-needed` to the linker if it's GNU ld which `wasm-ld` is not. Usually this isn't an issue for wasm as we would use the WasmLd linker driver but because the linker in question (`wasm32-unknown-wasi-wasm-ld`) ended with `-ld` our linker inferring [logic](https://github.com/rust-lang/rust/blob/f64503eb555475d65ae5503ef22439ca5dd394fd/compiler/rustc_codegen_ssa/src/back/link.rs#L957-L1040) used the `GccLinker` implementations. (UPD: The linker inferring logic actually didn't apply in this case because the linker is actually invoked through gcc in the reported issue. But it's still worth updating the logic I think.)
This change then has 2 parts:
1. Update wasm_base target spec to indicate `linker_is_gnu: false` plus a few additions of `target.is_like_wasm` to handle flags `wasm-ld` does in fact support.
2. Improve the linker detection logic to properly determine the correct flavor of wasm linker we're using when we can.
We need to add the new `target.is_like_wasm` branches to handle the case where the "linker" used could be something like clang which would then under the hood call wasm-ld.
|
|
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.
|
