Commit Graph

357 Commits

Author SHA1 Message Date
Mike Leany
8b6764c4ef Fix build errors. 2021-10-13 08:14:13 -06:00
Josh Triplett
2037cee701 x86_64-unknown-none: Expand TargetOptions to specify more details
Specify the `cpu` and the `max_atomic_width` (64).

Set `stack_probes` similarly to other targets to work around known
issues, and copy the corresponding comment from those targets.

Build position-independent code that doesn't require relocations.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:13 -06:00
Josh Triplett
6ab66192f9 x86_64-unknown-none: Disable more target features
Based on the list used for x86_64-unknown-none-linuxkernel.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
b0d1e3be23 x86_64-unknown-none: Drop the abi field
(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
b0efa05e5a x86_64-unknown-none: Fix module comment
(Work on this target sponsored by Profian.)
2021-10-13 08:14:12 -06:00
Josh Triplett
a23ee64c2c Rename x86_64-unknown-none-elf to x86_64-unknown-none
Most Rust freestanding/bare-metal targets use just `-unknown-none` here,
including aarch64-unknown-none, mipsel-unknown-none, and the BPF
targets. The *only* target using `-unknown-none-elf` is RISC-V.

The underlying toolchain doesn't care; LLVM accepts both `x86_64-unknown-none`
and `x86_64-unknown-none-elf`.

In addition, there's a long history of embedded x86 targets with varying
definitions for the `elf` suffix; on some of those embedded targets,
`elf` implied the inclusion of a C library based on newlib or similar.
Using `x86_64-unknown-none` avoids any potential ambiguity there.

(Work on this target sponsored by Profian.)
2021-10-13 08:14:09 -06:00
Mike Leany
5ba3a651f9 Use CodeModel::Kernel for x86_64-unknown-none-elf. 2021-10-13 08:13:00 -06:00
Mike Leany
80654c3d93 Fix code formatting. 2021-10-13 08:12:59 -06:00
Mike Leany
8aad5f45d5 Add new target: x86_64-unknown-none-elf 2021-10-13 08:12:50 -06:00
Jonah Petri
bc3eb354e7 add platform support details file for armv7-unknown-linux-uclibc 2021-10-06 14:33:13 +00:00
Yannick Koehler
11381a5a3a Add new target armv7-unknown-linux-uclibceabihf
Co-authored-by: Jonah Petri <jonah@petri.us>
2021-10-06 14:33:13 +00:00
bjorn3
83ddedf170 Remove various unused feature gates 2021-10-02 19:09:18 +02:00
Manish Goregaokar
6f1e930581
Rollup merge of #88820 - hlopko:add_pie_relocation_model, r=petrochenkov
Add `pie` as another `relocation-model` value

MCP: https://github.com/rust-lang/compiler-team/issues/461
2021-10-01 09:18:16 -07:00
Marcel Hlopko
198d90786b Add pie as another relocation-model value 2021-10-01 08:06:42 +02:00
Tomoaki Kawada
da9ca41c31 Add SOLID targets
SOLID[1] is an embedded development platform provided by Kyoto
Microcomputer Co., Ltd. This commit introduces a basic Tier 3 support
for SOLID.

# New Targets

The following targets are added:

 - `aarch64-kmc-solid_asp3`
 - `armv7a-kmc-solid_asp3-eabi`
 - `armv7a-kmc-solid_asp3-eabihf`

SOLID's target software system can be divided into two parts: an
RTOS kernel, which is responsible for threading and synchronization,
and Core Services, which provides filesystems, networking, and other
things. The RTOS kernel is a μITRON4.0[2][3]-derived kernel based on
the open-source TOPPERS RTOS kernels[4]. For uniprocessor systems
(more precisely, systems where only one processor core is allocated for
SOLID), this will be the TOPPERS/ASP3 kernel. As μITRON is
traditionally only specified at the source-code level, the ABI is
unique to each implementation, which is why `asp3` is included in the
target names.

More targets could be added later, as we support other base kernels
(there are at least three at the point of writing) and are interested
in supporting other processor architectures in the future.

# C Compiler

Although SOLID provides its own supported C/C++ build toolchain, GNU Arm
Embedded Toolchain seems to work for the purpose of building Rust.

# Unresolved Questions

A μITRON4 kernel can support `Thread::unpark` natively, but it's not
used by this commit's implementation because the underlying kernel
feature is also used to implement `Condvar`, and it's unclear whether
`std` should guarantee that parking tokens are not clobbered by other
synchronization primitives.

# Unsupported or Unimplemented Features

Most features are implemented. The following features are not
implemented due to the lack of native support:

- `fs::File::{file_attr, truncate, duplicate, set_permissions}`
- `fs::{symlink, link, canonicalize}`
- Process creation
- Command-line arguments

Backtrace generation is not really a good fit for embedded targets, so
it's intentionally left unimplemented. Unwinding is functional, however.

## Dynamic Linking

Dynamic linking is not supported. The target platform supports dynamic
linking, but enabling this in Rust causes several problems.

 - The linker invocation used to build the shared object of `std` is
   too long for the platform-provided linker to handle.

 - A linker script with specific requirements is required for the
   compiled shared object to be actually loadable.

As such, we decided to disable dynamic linking for now. Regardless, the
users can try to create shared objects by manually invoking the linker.

## Executable

Building an executable is not supported as the notion of "executable
files" isn't well-defined for these targets.

[1] https://solid.kmckk.com/SOLID/
[2] http://ertl.jp/ITRON/SPEC/mitron4-e.html
[3] https://en.wikipedia.org/wiki/ITRON_project
[4] https://toppers.jp/
2021-09-28 11:31:47 +09:00
the8472
26c7838118
Rollup merge of #89170 - rusticstuff:aarch64_macos_disable_leak_sanitizer, r=petrochenkov
Disable the leak sanitizer on Macos aarch64 for now

It is currently broken, see #88132.
2021-09-22 19:03:27 +02:00
Hans Kratz
59e37c829b Disable the leak sanitizer on Macos aarch64 for now.
It is currently broken, see #88132.
2021-09-22 08:05:34 +02:00
Mark Rousskov
c746be2219 Migrate to 2021 2021-09-20 22:21:42 -04:00
bors
db1fb85cff Auto merge of #88321 - glaubitz:m68k-linux, r=wesleywiser
Add initial support for m68k

This patch series adds initial support for m68k making use of the new M68k
backend introduced with LLVM-13. Additional changes will be needed to be
able to actually use the backend for this target.
2021-09-20 07:21:05 +00:00
Eduard-Mihai Burtescu
c1837ef1c5 Querify fn_abi_of_{fn_ptr,instance}. 2021-09-18 04:41:33 +03:00
Eduard-Mihai Burtescu
344df76fed ty::layout: intern FnAbis as &'tcx. 2021-09-18 01:42:45 +03:00
Eduard-Mihai Burtescu
7f2f927eb8 ty::layout: propagate errors up to (but not out of) FnAbi::of_*. 2021-09-18 01:42:44 +03:00
Eduard-Mihai Burtescu
4d36faf9ef rustc_target: adjust_for_cabi -> adjust_for_foreign_abi. 2021-09-18 01:42:43 +03:00
John Paul Adrian Glaubitz
580559129b compiler/rustc_target: Add support for m68k-linux-gnu 2021-09-17 15:07:12 +00:00
bors
9f85cd6f2a Auto merge of #87794 - bonega:enum_niche_prefer_zero, r=nagisa
Enum should prefer discriminant zero for niche

Given an enum with unassigned zero-discriminant, rust should prefer it for niche selection.
Zero as discriminant for `Option<Enum>` makes it possible for LLVM to optimize resulting asm.

- Eliminate branch when expected value coincides.
- Use smaller instruction `test eax, eax` instead of `cmp eax, ?`
- Possible interaction with zeroed memory?

Example:
```rust

pub enum Size {
    One = 1,
    Two = 2,
    Three = 3,
}

pub fn handle(x: Option<Size>) -> u8 {
    match x {
        None => {0}
        Some(size) => {size as u8}
    }
}
```
In this case discriminant zero is available as a niche.

Above example on nightly:
```asm
 mov     eax, edi
 cmp     al, 4
 jne     .LBB0_2
 xor     eax, eax
.LBB0_2:
 ret
```

PR:
```asm
 mov     eax, edi
 ret
```

I created this PR because I had a performance regression when I tried to use an enum to represent legal grapheme byte-length for utf8.

Using an enum instead of `NonZeroU8` [here](d683304f5d/src/internal/decoder_incomplete.rs (L90))
resulted in a performance regression of about 5%.
I consider this to be a somewhat realistic benchmark.

Thanks to `@ogoffart` for pointing me in the right direction!

Edit: Updated description
2021-09-13 22:14:57 +00:00
Andreas Liljeqvist
4d66fbc4b9 enum niche allocation grows toward zero if possible 2021-09-13 21:55:14 +02:00
bors
61a1029143 Auto merge of #88529 - Meziu:master, r=nagisa
ARMv6K Nintendo 3DS Tier 3 target added

Addition of the target specifications to build .elf files for Nintendo 3DS (ARMv6K, Horizon). Requires devkitARM 3DS toolkit for system libraries and arm-none-eabi-gcc linker.
2021-09-13 05:48:03 +00:00
Meziu
e07ae3ca26 ARMV6K 3DS: Removed useless parameters in target spec 2021-09-10 20:20:12 +02:00
Andreas Liljeqvist
bc95994c32 bugfix 2021-09-09 10:41:20 +02:00
Andreas Liljeqvist
a2ee1420b8 Wrap 2021-09-09 10:41:20 +02:00
Andreas Liljeqvist
9095cf9905 rename is_valid_for to is_valid 2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
dd34e0c966 Rename (un)signed to (un)signed_int 2021-09-09 10:41:19 +02:00
Andreas Liljeqvist
9129f4306f Move unsigned_max etc into Size again 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
86ff6aeb82 Fix docstring 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
da92cd6dcf Use special Debug format when start > end 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
f5d8749f85 Remove contains_zero, respect the compiler 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
021c3346ed derive Copy for WrappingRange and Scalar 2021-09-09 10:41:18 +02:00
Andreas Liljeqvist
4c46296f22 fix match 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
4878034c00 Auto merge of #88454 - devnexen:sunos_asan, r=wesleywiser
sunos systems add sanitizer supported.
2021-09-03 17:50:51 +00:00
bors
64929313f5 Auto merge of #88516 - matthiaskrgr:clippy_perf_end_august, r=jyn514,GuillaumeGomez
some low hanging clippy::perf fixes
2021-09-02 10:27:44 +00:00
bors
b27ccbc7e1 Auto merge of #87114 - cjgillot:abilint, r=estebank
Lint missing Abi in ast validation instead of lowering.
2021-09-02 06:06:24 +00:00
Eduard-Mihai Burtescu
4ce933f13f rustc_target: move LayoutOf to ty::layout. 2021-09-02 01:17:14 +03: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
Camille GILLOT
8d7d488d3b Lint Abi in ast validation. 2021-08-31 20:30:17 +02:00
Matthias Krüger
7f2df9ad65 some low hanging clippy::perf fixes 2021-08-31 20:29:04 +02:00
Meziu
8078c4c809 ARMv6K Nintendo 3DS Tier 3 target added 2021-08-31 14:11:23 +02:00
David Carlier
8539a3c001 sunos systems add sanitizer supported. 2021-08-30 18:49:56 +01:00