Tier 3 target proposal: riscv64gc-linux-android (Android target for riscv64gc
)
#472
Closed
17 of 19 tasks
Labels
major-change
A proposal to make a major change to rustc
major-change-accepted
A major change proposal that was accepted
T-compiler
Add this label so rfcbot knows to poll the compiler team
Proposal
This compiler MCP proposes a new target:
riscv64gc-linux-android
for RISC-V 64 bit Android target. The object file format for this target is ELF. In addition, there will be anstd
implementation for this target, just like all the Linux/Android targets.This target is intended to develop Android applications or AOSP itself on RISC-V 64 bit (w/ +g +c CPU features).
This target is very similar to the
riscv64gc-unknown-linux-gnu
and shares almost all the code generation processes and features with some changes to the linking step.This target is also very similar to the
aarch64-linux-android
because both are Android targets, and the linking step is the same.There is currently no plan to promote this target to Tier 2 as the necessary work on the official AOSP part has yet to begin. Thus, this target will be based upon the current effort made by the https://github.com/aosp-riscv organization.
Tier 3 Requirements Check
Zixing Liu, liushuyu011@gmail.com, https://github.com/liushuyu
The target name is derived from
riscv64gc-unknown-linux-gnu
(a Tier 2 w/ Host target) andaarch64-linux-android
(a Tier 2 w/o Host target). So the target name is consistent with the current naming scheme.This target will/only use a modified version of Android NDK to build and link the binary. The modified Android NDK is licensed under the same license as the official AOSP Android SDK per the requirement (Apache License 2.0).
The new code will not introduce license incompatibilities since no new libraries or dependencies will be introduced to the Rust compiler itself or the standard library.
MIT OR Apache-2.0
).The new code will be licensed under
MIT OR Apache-2.0
.As no new libraries or dependencies will be introduced to the Rust compiler itself or the standard library, there should be no new license requirements introduced.
rustc
orcargo
), those host tools must not depend on proprietary (non-FOSS) libraries, other than ordinary runtime libraries supplied by the platform and commonly used by other binaries built for the target. For instance,rustc
built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.The code generation is done purely using the existing Rust compiler's infrastructure (LLVM). No code generation modification is required.
The target uses
lld
from the LLVM project to link a binary or library, so there is no proprietary component requirement.I have reviewed the code changes and determined (to my best knowledge) that there should be no onerous legal issues to either the Rust project or its developers/users.
Affiliation: I am currently an intern at PLCT Laboratory.
N/A: I am not a Rust maintainer.
N/A: I don't have the approval privilege either on this MCP or target approval/promotion.
An
std
implementation will be provided as part of the target addition.Documentation explaining how to build and use the compiler for this target will be provided (to the best of my abilities) as part of the target addition.
Acknowledged.
I will make sure this target will not interfere or even break any other targets that the Rust compiler currently supports.
Acknowledged.
Mentors or Reviewers
If you have a reviewer or mentor in mind for this work, mention then
here. You can put your own name here if you are planning to mentor the
work.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
Comments
This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.
The text was updated successfully, but these errors were encountered: