| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Upgrade `log` to `0.4` in multiple crates.
|
|
Use the right TLS model for CloudABI.
CloudABI doesn't do dynamic linking. For this reason, there is no need
to handle any other TLS model than local-exec. CloudABI's C library
doesn't provide a __tls_get_addr() function to do Dynamic TLS.
By forcing local-exec to be used here, we ensure that we don't generate
function calls to __tls_get_addr().
|
|
|
|
CloudABI doesn't do dynamic linking. For this reason, there is no need
to handle any other TLS model than local-exec. CloudABI's C library
doesn't provide a __tls_get_addr() function to do Dynamic TLS.
By forcing local-exec to be used here, we ensure that we don't generate
function calls to __tls_get_addr().
|
|
|
|
This was originally brought in, because the definitions are based on
those of FreeBSD, Linux, etc. Even though CloudABI is based on POSIX, it
uses a subset that is so small that it's not reasonable to call it POSIX.
Now that I'm porting libstd, I'm running into some spots where I have to
explicitly disable code paths that were enabled by cfg(unix).
|
|
|
|
CloudABI is a sandboxed UNIX-like runtime environment. It is a
programming environment that uses a capability-based security model. In
practice this means that many POSIX interfaces are present, except for
ones that try to access resources out of thin air. For example, open()
is gone, but openat() is present.
Right now I'm at the point where I can compile very basic CloudABI
applications on all four supported architectures (ARM and x86, 32 and 64
bits). The next step will be to get libstd to work. Patches for that are
outside the scope of this change.
More info: https://nuxi.nl/cloudabi/ https://github.com/NuxiNL/cloudlibc/
|
|
Move rustc_back modules where they belong.
|
|
|
|
|
|
|
|
Not actually enabled by default anywhere yet.
|
|
disable jemalloc on executables for ios targets
This is a (temporary ?) workaround for issue #45262
|
|
|
|
|
|
|
|
This commit adds a new target to the compiler: wasm32-unknown-unknown. This
target is a reimagining of what it looks like to generate WebAssembly code from
Rust. Instead of using Emscripten which can bring with it a weighty runtime this
instead is a target which uses only the LLVM backend for WebAssembly and a
"custom linker" for now which will hopefully one day be direct calls to lld.
Notable features of this target include:
* There is zero runtime footprint. The target assumes nothing exists other than
the wasm32 instruction set.
* There is zero toolchain footprint beyond adding the target. No custom linker
is needed, rustc contains everything.
* Very small wasm modules can be generated directly from Rust code using this
target.
* Most of the standard library is stubbed out to return an error, but anything
related to allocation works (aka `HashMap`, `Vec`, etc).
* Naturally, any `#[no_std]` crate should be 100% compatible with this new
target.
This target is currently somewhat janky due to how linking works. The "linking"
is currently unconditional whole program LTO (aka LLVM is being used as a
linker). Naturally that means compiling programs is pretty slow! Eventually
though this target should have a linker.
This target is also intended to be quite experimental. I'm hoping that this can
act as a catalyst for further experimentation in Rust with WebAssembly. Breaking
changes are very likely to land to this target, so it's not recommended to rely
on it in any critical capacity yet. We'll let you know when it's "production
ready".
---
Currently testing-wise this target is looking pretty good but isn't complete.
I've got almost the entire `run-pass` test suite working with this target (lots
of tests ignored, but many passing as well). The `core` test suite is still
getting LLVM bugs fixed to get that working and will take some time. Relatively
simple programs all seem to work though!
---
It's worth nothing that you may not immediately see the "smallest possible wasm
module" for the input you feed to rustc. For various reasons it's very difficult
to get rid of the final "bloat" in vanilla rustc (again, a real linker should
fix all this). For now what you'll have to do is:
cargo install --git https://github.com/alexcrichton/wasm-gc
wasm-gc foo.wasm bar.wasm
And then `bar.wasm` should be the smallest we can get it!
---
In any case for now I'd love feedback on this, particularly on the various
integration points if you've got better ideas of how to approach them!
|
|
|
|
This commit removes the `rand` crate from the standard library facade as
well as the `__rand` module in the standard library. Neither of these
were used in any meaningful way in the standard library itself. The only
need for randomness in libstd is to initialize the thread-local keys of
a `HashMap`, and that unconditionally used `OsRng` defined in the
standard library anyway.
The cruft of the `rand` crate and the extra `rand` support in the
standard library makes libstd slightly more difficult to port to new
platforms, namely WebAssembly which doesn't have any randomness at all
(without interfacing with JS). The purpose of this commit is to clarify
and streamline randomness in libstd, focusing on how it's only required
in one location, hashmap seeds.
Note that the `rand` crate out of tree has almost always been a drop-in
replacement for the `rand` crate in-tree, so any usage (accidental or
purposeful) of the crate in-tree should switch to the `rand` crate on
crates.io. This then also has the further benefit of avoiding
duplication (mostly) between the two crates!
|
|
|
|
Similar to #36994, rust programs segfault on SPARC64 Solaris machines.
|
|
Add x86_64-unknown-linux-gnux32 target
This adds X32 ABI support for Linux on X86_64. Let's package and dist it so we can star testing libc, libstd, etc.
Fixes https://github.com/rust-lang/rfcs/issues/1339
|
|
cleanup: rustc doesn't use an external archiver
cc https://github.com/rust-lang/rust/pull/45090
r? @alexcrichton
|
|
|
|
Some targets, like msp430 and nvptx, don't work with multiple codegen units
right now for bugs or fundamental reasons. To expose this allow targets to
express a default.
Closes #45000
|
|
|
|
Remove support for the PNaCl target (le32-unknown-nacl)
This removes support for the `le32-unknown-nacl` target which is currently supported by rustc on tier 3. Despite the "nacl" in the name, the target doesn't output native code (x86, ARM, MIPS), instead it outputs binaries in the PNaCl format.
There are two reasons for the removal:
* Google [has announced](https://blog.chromium.org/2017/05/goodbye-pnacl-hello-webassembly.html) deprecation of the PNaCl format. The suggestion is to migrate to wasm. Happens we already have a wasm backend!
* Our PNaCl LLVM backend is provided by the fastcomp patch set that the LLVM fork used by rustc contains in addition to vanilla LLVM (`src/llvm/lib/Target/JSBackend/NaCl`). Upstream LLVM doesn't have PNaCl support. Removing PNaCl support will enable us to move away from fastcomp (#44006) and have a lighter set of patches on top of upstream LLVM inside our LLVM fork. This will help distribution packagers of Rust.
Fixes #42420
|
|
enable strict alignment (+strict-align) on ARMv6
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
closes #44538
r? @alexcrichton
|
|
As discovered in #44538 ARMv6 devices may or may not support unaligned memory accesses. ARMv6
Linux *seems* to have no problem with unaligned accesses but this is because the kernel is stepping
in to fix each unaligned memory access -- this incurs in a performance penalty.
This commit enforces aligned memory accesses on all our in-tree ARM targets that may be used with
ARMv6 devices. This should improve performance of Rust programs on ARMv6 devices. For the record,
clang also applies this attribute when targeting ARMv6 devices that are not running Darwin or
NetBSD.
|
|
|
|
The ARMv5te platform does not have instruction-level support for atomics, however the kernel provides [user space helpers](https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt) which can be used to perform atomic operations. When linked with `libc`, the atomic symbols needed by Rust will be provided, rather than CPU level intrinsics.
As this target is specifically `linux` and `gnueabi`, it is reasonable to assume the Linux Kernel and libc will be available for the target. There is a large performance penalty, as we are not using CPU level intrinsics, however this penalty is likely preferable to not having the target at all.
I have used this change in a custom target (along with `xargo`) to build `std`, as well as a number of higher level crates.
|
|
Fix regression from c2fe69b9, where main() signature was changed from
using 16bit isize to 32bit c_int for argc parameter/result.
|
|
(all i32 for now, as in liblibc)
|
|
Signed-off-by: Ben Cressey <bcressey@amazon.com>
Signed-off-by: Tom Kirchner <tjk@amazon.com>
|
|
This takes way longer than I thought it would. =)
|
|
|
|
The SystemZ `LALR` instruction provides PC-relative addressing for
globals, but only to *even* addresses, so other compilers make sure that
such globals are always 2-byte aligned. In Clang, this is modeled with
`TargetInfo::MinGlobalAlign`, and `TargetOptions::min_global_align` now
serves the same purpose for rustc.
In Clang, the only targets that set this are SystemZ, Lanai, and NVPTX,
and the latter two don't have targets in rust master.
|
|
haiku/librustc_back: Remove incorrect no_integrated_as
* Makes rust bootstrap incorrectly search for xxx.s vs xxx.0.s
* Not needed or incorrect fix for another issue.
|
|
* Makes rust bootstrap incorrectly search for xxx.s vs xxx.0.s
* Not needed or incorrect fix for another issue.
|
|
Fixes #41701.
|
|
r=alexcrichton
L4Re Target: Add the needed Libraries and locate them
Add the libraries and objects that have to be linked to a get working L4Re Binary using pre- and post-link-args. Additionaly some ld commands had to be passed.
* L4Re libraries and objects will be located by an environment variable.
* gcc libraries and objects will be located using a gcc call.
GCC is mandatory for this target, that might need documentation somewhere. As soon as something mandatory cannot be found, the compiler will panic. This is intended, because the functions involved don't allow the usage of a Result type. libgcc_eh is now passed using `-l` and crtbeginT.o and crtend.o are now located using `gcc -print-filename`.
|
|
Note that this commit does not affect mips-musl targets, as they do not
inherit from linux_musl_base.
|
|
Most UNIX-like platforms do not allow shared libraries to statically
link their own libc, as libc expects to have consistent process-global
state. On those platforms, when we do not have a shared libc available,
we must not attempt to link dylibs or cdylibs. On Windows, however, it
is expected to statically link the CRT into dynamic libraries.
This feature is only relevant for targets that support both fully-static
and fully-dynamic linkage, such as musl on Linux.
|
|
This feature allows targets to opt in to full support of the crt-static
feature. Currently, crt-static is allowed on all targets, even those
that really can't or really shouldn't support it. This works because it
is very loose in the specification of its effects. Changing the behavior
of crt-static to be more strict in how it chooses libraries and links
executables would likely cause compilation to fail on these platforms.
To avoid breaking existing uses of crt-static, whitelist targets that
support the new, stricter behavior. For all other targets, this changes
crt-static from being "mostly a no-op" to "explicitly a no-op".
|
|
If the environment variable L4RE_LIBDIR ist not set an Error will be
returned wrapped in a result type instead of a panic.
|
|
Add the libraries and objects that have to be linked to a get working L4Re
Binary using pre- and post-link-args. Additionaly some ld commands had to
be passed.
* L4Re libraries and objects will be located by an environment variable.
* gcc libraries and objects will be located using a gcc call.
GCC is mandatory for this target, that might need documentation somewhere.
As soon as something mandatory cannot be found, the compiler will panic.
This is intended, because the functions involved don't allow the usage of
a Result type. libgcc_eh is now passed using `-l` and crtbeginT.o and
crtend.o are now located using `gcc -print-filename`.
Co-authored-by: TobiasSchaffner <tobiasschaffner@outlook.com>
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
