about summary refs log tree commit diff
path: root/src/librustc_target
AgeCommit message (Collapse)AuthorLines
2019-08-31Add x86_64-linux-kernel targetAlex Gaynor-0/+60
This adds a target specification for Linux kernel modules on x86_64, as well as base code that can be shared with other architectures.
2019-08-16Rollup merge of #63604 - Wind-River:master, r=alexcrichtonMazdak Farrokhzad-198/+21
Some update for vxWorks 1. support crt-static 2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf. 3. change vx-cxx to wr-c++, vx-ar to wr-ar and vx-run to wr-run. 4. code cleanup r? @alexcrichton
2019-08-16Rollup merge of #63595 - semarie:openbsd-sparc64, r=alexcrichtonMazdak Farrokhzad-0/+23
add sparc64-unknown-openbsd target on OpenBSD, some architectures relies on libc++ (from LLVM) and some others on libestdc++ (particular version of libstdc++ from GCC). sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some years ago). Reintroduce the support of them for openbsd, only for sparc64 arch. Some others architectures on OpenBSD could use them too.
2019-08-15add sparc64-unknown-openbsd targetSébastien Marie-0/+23
on OpenBSD, some architectures relies on libc++ (from LLVM) and some others on libestdc++ (particular version of libstdc++ from GCC). sparc64-unknown-openbsd needs libestdc++ and libgcc (as x86_64 some years ago). Reintroduce the support of them for openbsd, only for sparc64 arch. Some others architectures on OpenBSD could use them too.
2019-08-15Rollup merge of #63467 - ↵Mazdak Farrokhzad-3/+31
terhechte:support-ios-catalyst-macabi-target-triple, r=estebank Add Catalyst (iOS apps running on macOS) target This is a first attempt of adding support for the new [Apple Catalyst](https://developer.apple.com/ipad-apps-for-mac/) target (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu, iOS SDK, linked agains the iOS ABI - Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI. Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. I've collected additional information via links in the open question sections below. This is way out of my comfort zone so please excuse whatever errors I may have made. # Open Questions: ## Clang Version It seems to me that `macabi` has not been merged into `clang` yet, I don't know whether that is a requirement rustc to compile, or if it is sufficient if the Clang that is used on a developers system is the correct one supporting macabi (that comes with current Xcode) ## Hardcoded iOS version `swift-llvm` actually used [x86_64-apple-ios13.0-macabi](https://github.com/apple/swift-llvm/commit/3f1fd4f46a8e82cee6fffb284ee46daf8ddf66ae) as the target triple which hard-codes the current iOS version. A post on stackoverflow [points out that `MIN_IOS_VERSION` and `MIN_OSX_VERSION` should be used when compiling C code for clang (`-target x86_64-apple-ios${MIN_IOS_VERSION}-macabi`)](https://stackoverflow.com/questions/56487645/how-to-compile-a-3rd-party-library-to-be-used-with-uikit-for-mac-catalyst). However, I wasn't entirely sure how to do that in this PR. Pointers welcome. ## Data Layout I'm probably using the wrong data-layout. I don't know whether it should be the macOS version or the iOS version. This is probably easier to answer for somebody who understands these things much better than me. I just copied the iOS Simulator X86_64 version as it seems to be (based on what I understand) that Catalyst is just the simulator target build against a different SDK. # Current State 1. I got it to compile 2. I could successfully compile a `macabi` `libcore` via `cargo build --target x86_64-apple-ios-macabi` I'm not sure what needs to be done next. Supposedly I need to compile everything into a toolchain somehow that I can then test via `rustup` to make sure that a binary compiled against the toolchain also works with Catalyst. [I read this article, but I'm still lost](https://www.reddit.com/r/rust/comments/5ag60z/how_do_i_bootstrap_rust_to_crosscompile_for_a_new/d9gicr2/) and would love pointers what to do next here. # Additional Information - [Commit adding Catalyst support to the Swift Clang Fork](https://github.com/CocoaPods/CocoaPods/issues/8877) - [Compiling C to Catalyst Discussion](https://github.com/CocoaPods/CocoaPods/issues/8877) - [CocoaPods Discussion on Adding Catalyst support](https://github.com/CocoaPods/CocoaPods/issues/8877)
2019-08-15Rollup merge of #63165 - xen0n:mips64-musl-targets, r=alexcrichtonMazdak Farrokhzad-0/+52
Add builtin targets for mips64(el)-unknown-linux-muslabi64 This is prerequisite for rust-lang/libc#1449. Tested locally to produce working static and dynamic binaries, ~~but CI config is untested for now~~ CI is to be added in a follow-up PR. *edit: dynamic binaries also confirmed working!* *edit 2: changed triples to include ABI, and removed stray `crt_static_default = false` declarations to be consistent with other musl targets*
2019-08-15Rollup merge of #63155 - mfkl:uwp-msvc, r=alexcrichtonMazdak Farrokhzad-0/+105
Add UWP MSVC targets Hi, - The README URI change is the correct one for VS2019 community edition, which I suspect most people would use. Doesn't _need_ to be merged though. - This https://github.com/rust-lang/rust/commit/5e6619edd1a3b5c3f85438166d4d32af49f800fd fixes the UWP build (msvc or not, doesn't matter). I suspect it broke with recent changes unnoticed because no CI. - Store lib location is found through the VCToolsInstallDir env variable. The end of the path is currently for the VS2019 store lib locations only. - I could not test the aarch64_uwp_windows_msvc target because the rust build script does not currently support arm64 msvc AFAIU.
2019-08-14Handle cfg(bootstrap) throughoutMark Rousskov-13/+6
2019-08-131. support crt-staticBaoshan Pang-198/+21
2. change armv7_wrs_vxworks to armv7_wrs_vxworks_eabihf. 3. use wr-** instead of vx-** 4. set PIE to false 5. code cleanup
2019-08-11Add initial files for iOS catalyst / macabi supportBenedikt Terhechte-3/+31
This is a first attempt of adding support for the new Apple Catalyst ABI (i.e. running iOS apps on macOS). Currently, `rustc` supports the iOS and iOS simulator targets for iOS: - iOS: ARM cpu, iOS SDK, linked agains the iOS ABI - Simulator: X86_64 cpu, iOS SDK, linked against the iOS ABI Apple Catalyst will add an additional target: - Macabi: X86_64 CPU, iOS SDK, linked again the macOS ABI. Note, it the actual SDK is the also the macOS 10.15 SDK, but the symbols are the iOS SDK symbols as they were added to macOS with 10.15. This commits adds the files for this new target triple.
2019-08-10rustc_target: add n64 musl targets for MIPS64 archesWang Xuerui-0/+52
Hard-float (unlike mips32 musl targets but consistent with any other musl target), MIPS64r2, n64 ABI. The triples are renamed to carry the `abi64` ABI suffix found on all other MIPS64 targets, for consistency and forward compatibility, should Rust gain support for the n32 ABI one day.
2019-08-08move store lib probing code to librustc_codegen_ssaMartin Finkel-40/+0
2019-08-07Auto merge of #60547 - redox-os:redox-unix, r=alexcrichtonbors-7/+31
redox: convert to target_family unix This is the second step to supporting rust-lang/rust#60139. In order to have a smooth transition, there will need to be a change made in liblibc at the same time, switching Redox over to the unix target family. See https://github.com/rust-lang/libc/pull/1332
2019-08-07Auto merge of #63152 - estebank:big-array, r=oli-obkbors-0/+4
Always error on `SizeOverflow` during mir evaluation Fix #55878, fix #25116. r? @oli-obk
2019-08-06redox: convert to target_family unixJeremy Soller-7/+31
2019-08-05review feedback: find lib root path from registryMartin Finkel-9/+19
2019-08-04review comments: clean upEsteban Küber-1/+1
2019-08-03Simplify change to layout_ofEsteban Küber-1/+3
2019-08-03Point to local place span on "type too big" errorEsteban Küber-0/+2
2019-08-03Rollup merge of #63107 - adrian-budau:master, r=alexcrichtonMazdak Farrokhzad-0/+65
Added support for armv7-unknown-linux-gnueabi/musleabi Fixes #63101 Some things that are not done and I hope someone can help me with: * During the ci build of `armv7-unknown-linux-gnueabi` `openssl` must be built (to build cargo) but `openssl` does not yet support this target. This feels slightly like a chicken-and-egg problem, any feedback is welcome. * Should I add any tests for any of these targets?
2019-08-02Added support for armv7-unknown-linux-gnueabi and armv7-unknown-linux-musleabi.Adrian Budau-0/+65
Support for the targets in the compiler and std build in the CI.
2019-08-02librustc_target: Unconfigure tests during normal buildVadim Petrochenkov-27/+31
2019-07-31Fix tidy checksMartin Finkel-9/+24
2019-07-31Add UWP MSVC targetsMartin Finkel-0/+120
2019-07-29Rollup merge of #62809 - alexcrichton:wasm-llvm-9, r=nikicMazdak Farrokhzad-0/+8
rustc: Update wasm32 support for LLVM 9 This commit brings in a number of minor updates for rustc's support for the wasm target which has changed in the LLVM 9 update. Notable updates include: * The compiler now no longer manually inserts the `producers` section, instead relying on LLVM to do so. LLVM uses the `llvm.ident` metadata for the `processed-by` directive (which is now emitted on the wasm target in this PR) and it uses debuginfo to figure out what `language` to put in the `producers` section. * Threaded WebAssembly code now requires different flags to be passed with LLD. In LLD we now pass: * `--shared-memory` - required since objects are compiled with atomics. This also means that the generated memory will be marked as `shared`. * `--max-memory=1GB` - required with the `--shared-memory` argument since shared memories in WebAssembly must have a maximum size. The 1GB number is intended to be a conservative estimate for rustc, but it should be overridable with `-C link-arg` if necessary. * `--passive-segments` - this has become the default for multithreaded memory, but when compiling a threaded module all data segments need to be marked as passive to ensure they don't re-initialize memory for each thread. This will also cause LLD to emit a synthetic function to initialize memory which users will have to arrange to call. * The `__heap_base` and `__data_end` globals are explicitly exported since they're now hidden by default due to the `--export` flags we pass to LLD.
2019-07-28Deny `unused_lifetimes` through rustbuildVadim Petrochenkov-2/+0
2019-07-28Remove lint annotations in specific crates that are already enforced by ↵Vadim Petrochenkov-3/+0
rustbuild Remove some random unnecessary lint `allow`s
2019-07-28Get out of bootstrapping pickle.Mazdak Farrokhzad-7/+22
2019-07-26Rollup merge of #62904 - nikic:arm-d32, r=alexcrichtonMazdak Farrokhzad-4/+4
Disable d32 on armv6 hf targets We already do this on armv7 targets. It seems that this now gets enabled by default if '+vfp2` is specified, so disable it explicitly. Hopefully fixes #62841. r? @alexcrichton
2019-07-26Rollup merge of #62801 - bjorn3:remove_lower_128bit_ops, r=alexcrichtonMazdak Farrokhzad-5/+0
Remove support for -Zlower-128bit-ops It is broken and unused cc https://github.com/rust-lang/rust/issues/58969 blocked https://github.com/rust-lang-nursery/compiler-builtins/pull/302 (removes definitions of the lang items removed in this PR) r? @alexcrichton
2019-07-26Rollup merge of #62692 - eddyb:precompute-niches, r=oli-obkMazdak Farrokhzad-0/+71
rustc: precompute the largest Niche and store it in LayoutDetails. Since we only ever can use at most one niche, it makes sense to just store that in the layout, for the simplest caching (especially as it's almost trivial to compute). There might be a speedup from this, but even if it's marginal now, the caching would be a more significant benefit for future optimization attempts.
2019-07-25Add UWP mingw targetsHugo Beauzée-Luyssen-0/+116
2019-07-25std: Use native `#[thread_local]` TLS on wasmAlex Crichton-0/+8
This commit moves `thread_local!` on WebAssembly targets to using the `#[thread_local]` attribute in LLVM. This was recently implemented upstream and is [in the process of being documented][dox]. This change only takes affect if modules are compiled with `+atomics` which is currently unstable and a pretty esoteric method of compiling wasm artifacts. This "new power" of the wasm toolchain means that the old `wasm-bindgen-threads` feature of the standard library can be removed since it should now be possible to create a fully functioning threaded wasm module without intrusively dealing with libstd symbols or intrinsics. Yay! [dox]: https://github.com/WebAssembly/tool-conventions/pull/116
2019-07-25Rollup merge of #62903 - swolchok:ios-sdkroot, r=alexcrichtonMazdak Farrokhzad-0/+14
Support SDKROOT env var on iOS Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun. Replaces #62551.
2019-07-25Rollup merge of #62901 - petrochenkov:serde, r=CentrilMazdak Farrokhzad-7/+4
cleanup: Remove `extern crate serialize as rustc_serialize`s
2019-07-25Rollup merge of #62814 - androm3da:hexagon_19jul_2019, r=alexcrichtonMazdak Farrokhzad-0/+37
add support for hexagon-unknown-linux-musl
2019-07-25Rollup merge of #62784 - Disasm:riscv32i, r=estebankMazdak Farrokhzad-0/+33
Add riscv32i-unknown-none-elf target This target is likely to be useful for constrained FPGA soft-cores, such as picorv32 and HeavyX.
2019-07-24Add commentScott Wolchok-0/+6
2019-07-24Auto merge of #62908 - ↵bors-1/+1
fakenine:normalize_use_of_backticks_compiler_messages_p17, r=alexreg normalize use of backticks for compiler messages in remaining modules https://github.com/rust-lang/rust/issues/60532
2019-07-23normalize use of backticks for compiler messages in remaining modulesSamy Kacimi-1/+1
https://github.com/rust-lang/rust/issues/60532
2019-07-23fix checkScott Wolchok-1/+2
2019-07-23Disable d32 on armv6 hf targetsNikita Popov-4/+4
2019-07-23cleanup: Remove `extern crate serialize as rustc_serialize`sVadim Petrochenkov-7/+4
2019-07-22add support for hexagon-unknown-linux-muslBrian Cain-0/+37
2019-07-20Revert "Disable stack probing for gnux32."CrLF0710-2/+1
This reverts commit 42d652ecd6709b756d95fc42615b166aacd2ea07.
2019-07-19Remove support for -Zlower-128bit-opsbjorn3-5/+0
It is broken and unused
2019-07-18Add riscv32i-unknown-none-elf targetVadim Kaushan-0/+33
2019-07-17update data_layout and featuresBaoshan Pang-6/+4
2019-07-16Support SDKROOT env var on iOSScott Wolchok-0/+7
Following what clang does (https://github.com/llvm/llvm-project/blob/296a80102a9b72c3eda80558fb78a3ed8849b341/clang/lib/Driver/ToolChains/Darwin.cpp#L1661-L1678), allow allow SDKROOT to tell us where the Apple SDK lives so we don't have to invoke xcrun.
2019-07-16Auto merge of #61946 - BaoshanPang:vxworks, r=alexcrichtonbors-1/+398
port rust for vxWorks The supporting for vxWorks has been enabled in this branch. Although there are still a lots of work to do, I would like to upstream the code and fix the problems later. Please let me know if there is anything I have to do before upstream the code. r? @alexcrichton Thanks, Baoshan
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-11 17:48:42 +0000