Naming convention for Rust target platforms

Tue Jan 30 21:20:17 UTC 2024

On Tue, Jan 30, 2024 at 3:15 PM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Tue, Jan 30, 2024 at 11:13 AM Frank Kühndel <
> frank.kuehndel at embedded-brains.de> wrote:
>
>> Hello Jan,
>>
>> On 1/29/24 19:41, Jan.Sommer at dlr.de wrote:
>> > Hi everyone,
>> >
>> > As mentioned in the other Rust thread, I am working on an initial Rust
>> port for RTEMS.
>> > The target platform for testing is the ARM Xilinx Zynq-7000 based BSPs.
>> > Where I am not completely sure, is how to name the new target for Rust
>> (see here the current list:
>> https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3).
>> > The Rust ARM targets usually have the instruction set version and ABI
>> as part of the name, e.g. armv7a-none-eabihf.
>> > In RTEMS the arm-rtems6-gcc covers all supported ARM versions and
>> different ABIs (i.e. hard-float or soft-float) collectively.
>> >
>> > So, for the Zynq and similar BSPs this would yield for the Rust target
>> something like: armv7a-rtems6-eabihf (and possibly armv7a-rtems6-eabi).
>> > Similarly, for other ARM BSPs additional Rust targets would need to be
>> added. Which might add up to quite a  number of Rust targets over time.
>> > Is this fine or do you see another solution?
>> Just to make sure I understand your question correct:
>> You want to push the RTEMS support you have developed (changes to Rust
>> libraries, test framework, ability to have a main() in the Rust code for
>> RTEMS etc.) to the official Rust repository - so that it is available to
>> everyone through the Rust nightly builds?
>>
>> If this is so, then your question would be primarily a question to the
>> Rust folks because it is their repository which would possibly receive
>> many different entries for (similar?) RTEMS BSPs?
>>
>> As far as I understand this, the steps for an RTEMS developer would be:
>>
>> 1) Build the right RTEMS tools with the Source Builder. Here: ARM tools.
>> 2) Build RTEMS (kernel) for the right (RTEMS) BSP
>> 3) Install the Rust compiler and its tools
>> 4) Create a Rust project
>> 5) Fine tune some Rust configuration files in that project.
>>     Here the "armv7a-rtems6-eabihf" or something fitting the BSP would
>>     be used in a config file. The point is, it must be for the processor
>>     and BSP which matches the RTEMS tools and BSP selected in steps 1)
>>     and 2)
>> 6) Make changes to the sample Rust code generated in the project
>>     or write the Rust code desired.
>> 7) Load the nightly build of the Rust compiler.
>>     (The nightly is only needed as long as your code has not entered the
>>     stable build).
>> 8) Compile the Rust program code with the Rust nightly compiler.
>> 9) Link the Rust binary with the RTEMS libraries into a single
>>     executable (using a linker build by the RTEMS tools).
>>
>> Which name Rust accepts instead of "armv7a-rtems6-eabihf" depends on the
>> naming convention of the Rust community:
>>      https://docs.rust-embedded.org/embedonomicon/custom-target.html
>> According to this file, the part `eabi` is for bare metal. Would this be
>> correct when it is based on RTEMS? For example, a Linux target would be
>> "x86_64-unknown-linux-gnu" where `gnu` means started by 'glibc'.
>>
>
> This is the more correct target name. We have worked hard for GCC,
> binutils,
> etc. to not have any BSP specific knowledge. They know about processor
> architectures and processor variations (e.g. core models) within each
> family.
> GCC may include shortcuts with SoC names as arguments but those just
> map to the proper arguments for the CPU core on the SoC. There is no
> implication of device support of any kind, much less a full BSP.
>
> Is there no notion of multilib in the Rust tooling?
>

I should have also mentioned that the bare metal nature of the *-eabi nature
as Frank noted has implications. It selects different configurations of
support
libraries which I assume Rust is layered on. The *-rtems* tool target
enables
the multithread safety and RTEMS awareness in various libraries. We may use
the same object format as the bare metal target but the library build
configurations
are quite different.

>
>
>>
>> By the way, section "Adding a new target" of
>>     https://doc.rust-lang.org/nightly/rustc/target-tier-policy.html
>> points to an example:
>>     https://github.com/rust-lang/rust/pull/94872
>> and that person discussed that triple name here:
>>
>>
>> https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/LLVM.2Bmingw-w64.20Windows.20targets
>>
>> Greetings,
>> Frank
>> >
>> > Cheers,
>> >
>> >
>> >      Jan
>> >
>> > Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
>> > German Aerospace Center
>> > Institute for Software Technology | Software for Space Systems and
>> Interactive Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany
>> >
>> > Jan Sommer
>> > Telephone +49 531 295-2494 | Telefax 0531 295-2767 |jan.sommer at dlr.de
>> > DLR.de/SC
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> >
>>
>> --
>> embedded brains GmbH & Co. KG
>> Herr Frank KÜHNDEL
>> Dornierstr. 4
>> 82178 Puchheim
>> Germany
>> email: frank.kuehndel at embedded-brains.de
>> phone:  +49-89-18 94 741 - 23
>> mobile: +49-176-15 22 06 - 11
>>
>> Registergericht: Amtsgericht München
>> Registernummer: HRA 117265
>> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
>> Unsere Datenschutzerklärung finden Sie hier:
>> https://embedded-brains.de/datenschutzerklaerung/
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240130/97615635/attachment.htm>