-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add x86_64-unknown-linux-none target #125023
Conversation
r? compiler-team |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @GuillaumeGomez (or someone else) some time within the next two weeks. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
Some changes occurred in src/doc/rustc/src/platform-support cc @Nilstrieb These commits modify compiler targets. |
There are merge commits (commits with multiple parents) in your changes. We have a no merge policy so these commits will need to be removed for this pull request to be merged. You can start a rebase with the following commands:
The following commits are merge commits: |
r? nielstrieb |
Failed to set assignee to
|
r? nilstrieb |
Arf didn't see that the reviewer was already changed... Putting back estebank. r? estebank |
This comment has been minimized.
This comment has been minimized.
449525d
to
9cf0800
Compare
Removed the merge commit, sorry about that |
This comment has been minimized.
This comment has been minimized.
@morr0ne could you more fully explain the intended distinction between this target and the |
More particularly, I believe it should be clear from day 0 what the stdlib impls are supposed to be. It is not required that those implementations should be done, and it is fully possible for those to vary in details on the journey to implementation, but I believe it makes it much harder to follow platform support processes if "I intend to" is hedged into "might be possible maybe someday or not". |
The existing *-gnu targets make the assumption that the target system is running a gnu environment, which in pratice means assuming glibc and the corresponding linker are present. This new target is intended for targets that make zero assumption about the environment beside the underlining kernel (linux) conventions.
I have been using this target in my own projects for months at this point and the benefit is clear. Without this target there are workarounds to achieve the same goals but they piggyback off the existing gnu targets. This way we have a target that clearly states that we are running without a libc
Maybe I could have worded it better. Having std and alloc for this target is 100% possible, I have zero doubts about that. The "might" stems from me not knowing if that is within the scope of rust since that would require shipping an allocator with std. I can't confidently say "this target will support std and alloc" because I don't know if the rust projects wants such support for an enviroment-less target. What I can say is that if there's consensus and interest, it is possible to implement std and alloc |
To further expand on my previous comment. The *-gnu targets assume the compiled binary will run on a GNU/Linux system. This new target is meant to target only Linux itself. |
Aha, okay! So you would be be happy to have this target with such implementations but also would be reasonably content without such implementations. Thank you, that clarifies the intent. |
It could be documented as such. But unless we have std we actually have no guarantee of such version. We might find out we actually can use a lower version, although unlikely.
Linux actually is the only mainstream os/kernel that allows us to make syscall directly. The userspace abi is stable and there is no standard libc. In a sense, there is no "runtime system" to coordinate with. There are many ways to make such syscalls but I believe the best solution is rustix, which I linked above.
The point of this target is exactly to guarantee no libc is linked. Linux doesn't forces you to link to a libc implementation and even if that were the case, there is no issue calling direct syscalls even if linking to libc. There is no requirement to make syscalls from libc on linux, regardless of the target environment.
The point of the target is to guarantee that we are running on top of the linux kernel. How syscalls are then made is up to the user in a no_std environments or up to std, however it decides to implement such calls.
We can ask the os via syscalls the same way the libc implementation does. Unlike other OSes, libc is not special on linux. There is nothing libc can do that we cannot do ourselves by calling direct syscalls or reading special virtual filesystems like /proc
I do not know how std::arch::is_x86_feature_detected is implemented but I assume it is calling some libc function that can be replaced by our own implementation |
Co-authored-by: Trevor Gross <t.gross35@gmail.com>
This is not entirely true, libcs generally do not appreciate you calling some syscalls directly without talking to them first. This is of course a non-issue when the libc is not in the address space at all, but when it is linked in some other way, that can lead to problems (one example being the forking syscalls). I assume that's what the person meant. Adding this target as a tier 3 no_std target makes sense. Any library implementation for this target should go to the libs team first to decide whether this is something that is desired in the first place. Given that the target won't really rely on Linux kernel features for now, documenting the minimum version doesn't make that much sense imo - it's as low as anyone wants (though you can write something there if you feel like it). It would of course also need to be specified when adding a library implementation or relying on features. |
Maybe I missunderstood what they meant. Regardless this is a non issue since libc will not be linked in any way for this target.
That was exactly my thought process. Adding this as a tier 3 makes this easy to merge without issues and any library implementation can be properly discussed at a later point.
I fully agree with this and is exactly why I did not add a version in the documentation. |
In that case, this is good to merge. I will approve this PR, adding a new tier 3 no_std target for bare Linux without libc. It does not commit to a rustix (or other)-based implementation of the standard library for bare Linux in the future (this should be discussed with the libs team first). @bors r+ |
for things like |
☀️ Test successful - checks-actions |
Finished benchmarking commit (31026b7): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 676.788s -> 675.763s (-0.15%) |
no rustc-timer, that's noise |
Noise, this shouldn't have changed perf. @rustbot label: +perf-regression-triaged |
Yeah, for the purpose of the version, I literally asked so that if some time months down the line someone has to archaeology up the original PR for this target, that there is indeed an intention captured there regarding what version was intended. Even like a... ballpark. It's of course fine to not write it down since it does not matter yet and doesn't reflect an actual promise.
@morr0ne For x86-64, it actually is entirely assembly. |
That is actually great to hear. It means we don't need to worry about the implementation |
Update Rust toolchain from nightly-2024-05-14 to nightly-2024-05-15 without any other source changes. This is an automatically generated pull request. If any of the CI checks fail, manual intervention is required. In such a case, review the changes at https://github.com/rust-lang/rust from rust-lang@ab14f94 up to rust-lang@8387315. The log for this commit range is: rust-lang@8387315ab3 Auto merge of rust-lang#125125 - lovesegfault:opt-dist-specify-rustc-perf, r=Mark-Simulacrum rust-lang@c3c9783de2 feat(tools/opt-dist): allow local builds to specify a rustc-perf checkout rust-lang@ac385a5af6 Auto merge of rust-lang#125120 - compiler-errors:rollup-mnjybwv, r=compiler-errors rust-lang@31016d5879 Rollup merge of rust-lang#125118 - GuillaumeGomez:cleanup-run-make, r=jieyouxu rust-lang@d59f430eec Rollup merge of rust-lang#125100 - compiler-errors:faster, r=nnethercote rust-lang@712e7c37f7 Rollup merge of rust-lang#125088 - compiler-errors:uplift-alias-ty, r=lcnr rust-lang@8c64acdbdc Rollup merge of rust-lang#125080 - bvanjoi:fix-124946, r=nnethercote rust-lang@844c7e826e Rollup merge of rust-lang#125047 - Oneirical:test5, r=jieyouxu rust-lang@0458d8a53b Rollup merge of rust-lang#124844 - compiler-errors:shadow-probe, r=lcnr rust-lang@36287830a2 Rollup merge of rust-lang#119838 - joshtriplett:style-guide-binop-indent, r=compiler-errors rust-lang@ade33b02f2 only find segs chain for missing methods when no available candidates rust-lang@bdfd941f4d Auto merge of rust-lang#123816 - tgross35:f16-f128-mangling, r=michaelwoerister rust-lang@f97d915173 Use new utility functions/methods in run-make tests rust-lang@792a9bdd4b Enable v0 mangling tests and add checks for `f16`/`f128` rust-lang@809b84edba Add v0 symbol mangling for `f16` and `f128` rust-lang@31026b7fe3 Auto merge of rust-lang#125023 - morr0ne:linux-none-target, r=Nilstrieb rust-lang@68407f9049 fix typo in x86_64-unknown-linux-none docs rust-lang@c45e831d8f Auto merge of rust-lang#124228 - compiler-errors:lint-overcaptures, r=oli-obk rust-lang@58426f4a5b Auto merge of rust-lang#125026 - Oneirical:clink-tests, r=jieyouxu rust-lang@e098eb14ae Wording improvement rust-lang@e2d9c0d938 Fix missing word rust-lang@57c32a193f style-guide: When breaking binops handle multi-line first operand better rust-lang@dbd2ca6478 Use a proper probe for shadowing impl rust-lang@052de1da4f And finally add tests rust-lang@1529c661e4 Warn against redundant use<...> rust-lang@f3fb727b08 Don't suggest using use<> syntax to capture APITs rust-lang@6afe1352d9 Suggest adding use<> syntax rust-lang@554becc180 Add some commenting rust-lang@d57e57ca1f Implement initial IMPL_TRAIT_OVERCAPTURES lint rust-lang@8f97a2588c Add test to make sure suggestions are still quick rust-lang@fba5f44bd8 Auto merge of rust-lang#125098 - jhpratt:rollup-2qm4gga, r=jhpratt rust-lang@45b50d303c lto function, static_library call, rename rust-lang@9f8cdb286e Remove to_term rust-lang@1ad28a6f53 Uplift AliasTy rust-lang@812f89728a fix fmt rust-lang@2e4c90c3f7 Don't do post-method-probe error reporting steps if we're in a suggestion rust-lang@32d74f1800 Rollup merge of rust-lang#125090 - erickt:bump-fuchsia, r=tmandry rust-lang@209703af85 Rollup merge of rust-lang#125072 - Darksonn:pin-dyn-dispatch-sound, r=jhpratt rust-lang@18d9c039bb Rollup merge of rust-lang#124997 - gurry:124848-ice-should-be-sized, r=Nadrieril rust-lang@74a78af0e2 Rollup merge of rust-lang#116675 - joshlf:patch-10, r=scottmcm rust-lang@9105c57b7f Auto merge of rust-lang#124256 - nnethercote:rm-NtIdent-NtLifetime, r=petrochenkov rust-lang@34582118af Auto merge of rust-lang#125076 - compiler-errors:alias-term, r=lcnr rust-lang@95e519ecbf Remove `NtIdent` and `NtLifetime`. rust-lang@fa84018c2e Apply nits rust-lang@58ee9192e0 Migrate fuchsia docs from `pm` to `ffx` rust-lang@293b5cb1ca [ptr] Document maximum allocation size rust-lang@3bcdf3058e split out AliasTy -> AliasTerm rust-lang@b3a78c1d09 Add test for dynamic dispatch + Pin::new soundness rust-lang@9a63a42cb7 Remove a `Span` from `TokenKind::Interpolated`. rust-lang@71fd2cf5b4 fix function call and import rust-lang@a1b5ea0cc2 make tidy happy rust-lang@f2de5fb2ae rewrite issue-14500 to rmake rust-lang@a6f237ca85 docs: fix typo in platform-support docs rust-lang@923cdb35aa test: Add assembly tests for x86_64-unknown-linux-none target rust-lang@10c358f111 Make tidy happy rust-lang@e37d2989c1 remove trailing whitespace rust-lang@a2e7e79a13 Port c-link-to-rust-va-list-fn to Rust rust-lang@9cf080099d docs: Document x86_64-unknown-linux-none target rust-lang@a3ef01b1fc Add x86_64-unknown-linux-none target rust-lang@fb619ec208 FIx ICE while casting a type with error Co-authored-by: tautschnig <1144736+tautschnig@users.noreply.github.com>
If I am reading this good news correctly it means that I can build pure Rust programs to this target and have Docker images use |
Yes and no. The ultimate objective is to achieve fully independent rust programs, but this is an initial step since there is no std or alloc implementation available. This target does support completely independent binaries, but as of now, it requires assistance from crates like Nevertheless, it is feasible to use this target in the manner you described. |
@morr0ne could you open a tracking issue for the |
Adds a freestanding linux binary with no libc dependency. This is useful for writing programs written only in rust. It is also essential for writing low level stuff like libc or a dynamic linker.
Tier 3 policy:
I will be the designed maintainer for this target
The target triple is consistent with other targets
There is no confusion with other targets since it explicitly adds "none" at the end instead of omitting the environment
The target does not introduce any unusual requirement
There are no license incompatibilities
Everything added is under that license
There are no new dependencies
There is no proprietary dependencies
No such terms exist for this target
Understood
The target already implements core. It might be possible in the future to add support for alloc and std by leveraging crates such as origin and rustix
I believe the proper docs are added
Understood
No other targets are effected
The same backends used by other linux targets work without issues