Naming convention for Rust target platforms
Karel Gardas
karel at functional.vision
Wed Jan 31 06:42:51 UTC 2024
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?
As I wrote in reply to Frank. I would go with 'armv7-rtems-eabi/hf'
here. I'm not even sure about eabi/hf thing. Do you know about any armv7
target *supported* by RTEMS which does not provide FPU? If not, then
waiting/mentally allocating 'eabi' and hurting others with a need to
type 'eabihf' for this case does not make sense and I would strip
'eabihf' too...
Thanks,
Karel
More information about the devel
mailing list