-
Notifications
You must be signed in to change notification settings - Fork 12.1k
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. |
At the moment I can't really say I have strong requirements for a version. To actually be useful without a libc it definitely needs to rely on more modern versions of the kernel, at least compared to the existing *-gnu targets. It is hard to pin-point a specific version however and I am happy to leave it somewhat unspecified, at least until there is a clear path forward to implement std and alloc. Generally speaking this target can be assumed to be somewhat bleeding edge. At the moment I work with the latest stable release of the kernel so it would be hard to notice if something is broken on older kernels |
@Nilstrieb do you want to snipe this review? I won't be around for a few days and this seems out of my wheelhouse. @workingjubilee thank you for taking on digging deeper on this! |
It would be good to document that an unknown kernel version, which is known to be greater than 3.19, because this affects whether On Linux, it is normally required to route all direct syscall calls through libc's In particular, how would we ask the OS to allocate memory for us to implement a heap? What is the minimum CPU feature set for this target? Since we cannot use (IIUC) libstd's |
src/doc/rustc/src/platform-support/x86_64-unknown-linux-none.md
Outdated
Show resolved
Hide resolved
Some background discussion at https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Direct.20syscalls.20on.20Linux, more in the vein of a std support. Having this target will be awesome. |
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 |
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