AW: Naming convention for Rust target platforms

Wed Jan 31 16:24:50 UTC 2024

> -----Ursprüngliche Nachricht-----
> Von: Frank Kühndel <frank.kuehndel at embedded-brains.de>
> Gesendet: Dienstag, 30. Januar 2024 18:14
> An: Sommer, Jan <Jan.Sommer at dlr.de>; devel at rtems.org
> Betreff: Re: Naming convention for Rust target platforms
> 
> 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).

Yes, that is my current process.
There might be some possibility to simplify step 5 that you use the
Information of the pkgconfig to figure most things out. 
Then you only need to set which BSP you want to build for
and have the pkgconfig paths set correctly.
It's still WIP for me right now.

> 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'.
> 
> 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/