AW: Naming convention for Rust target platforms

Wed Jan 31 16:59:00 UTC 2024

Hm. Somehow Outlook botched the inline quotes of the html mail.
Does it work now?

Von: Joel Sherrill <joel at rtems.org>
Gesendet: Mittwoch, 31. Januar 2024 16:57
An: Karel Gardas <karel at functional.vision>
Cc: Frank Kühndel <frank.kuehndel at embedded-brains.de>; Sommer, Jan <Jan.Sommer at dlr.de>; devel at rtems.org
Betreff: Re: Naming convention for Rust target platforms

On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas <karel at functional.vision<mailto:karel at functional.vision>> wrote:
On 1/30/24 18:13, Frank Kühndel wrote:
> 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 not completely fair to Jan as the x86_64 example is quite the
exception instead of a common norm in rust platforms names. But you
started with Linux so let's continue with Linux -- see the listing below.

Also IMHO this convention is not about rust per se, but IMHO about LLVM
way of doing things. GCC does that differently. So no C vs Rust, but GCC
vs. LLVM. Once Rust in GCC happen it'll be done in GCC more RTEMS used
way probably...

So for Rust/LLVM I think Jan's proposal is about right except that I
would strip '6' from rtems6. Neither OS (Linux, FreeBSD, NetBSD,
Windows, OpenBSD, VxWorks, etc) uses any version notion in the OS name
anyway... And also would strip 'a' from arm7a. We do not need to mention
'a' here explicitly since for 'm' we do have whole family of 'thumb*'
platform names... E.g. VxWorks in this particular case (ARMv7-A) uses:
armv7-wrs-vxworks-eabihf

WRS took the vendor part of the triple and I would not judge correctness
on what they did.

I have reached out to a contact at a company that has a long history of
supporting the GNU tools and has added Rust to their services in the past
few years. I would like to hear their opinion.

Thanks a lot, so far I just used the armv7a-none-eabihf as a baseline and added
“rtems” to it as I was more focused on the actual porting. Now, for going official
I have to fix the annoying little details. My hope is that if we get a good
solution here once and accepted by the Rust community that this paves
the way for other ports.

If I understand your comments regarding binutils correctly then maybe
Something like armv7-rtems-gnueabi(hf) would be more appropriate?

Cheers,
    Jan

Cheers,
Karel

On these, they actually do distinguish the OS. I see Linux, Android, and Open
Harmony.

There is also a distinction in the target name for C library used. I see glibc,
musl, and ulibc.

The rest of the target names are multilib variants and appear to reflect a lack
of support for or use of multilibs.

IMO this naming seems to reflect a Linux focus and a lack of understanding
of the processor variations seen in the embedded world.

If this is the final pattern, it may work for RTEMS because people build their
own tools and tend to use 1-2 BSPs. But it will be painful for developers testing
multiple BSPs, etc. My cron sweeper builds almost 20 tool chains now. With this,
we would be between 100 and 200 I expect. Some of the BSPs will have a similar
enough processor to share a tool chain but a lot won't.

I am glad you are working through this and this issue isn't a blocker for ironing
out a long list of other potential issues.

--joel

$ rustc --print target-list|grep linux
aarch64-linux-android
aarch64-unknown-linux-gnu
aarch64-unknown-linux-gnu_ilp32
aarch64-unknown-linux-musl
aarch64-unknown-linux-ohos
aarch64_be-unknown-linux-gnu
aarch64_be-unknown-linux-gnu_ilp32
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armeb-unknown-linux-gnueabi
armv4t-unknown-linux-gnueabi
armv5te-unknown-linux-gnueabi
armv5te-unknown-linux-musleabi
armv5te-unknown-linux-uclibceabi
armv7-linux-androideabi
armv7-unknown-linux-gnueabi
armv7-unknown-linux-gnueabihf
armv7-unknown-linux-musleabi
armv7-unknown-linux-musleabihf
armv7-unknown-linux-ohos
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
csky-unknown-linux-gnuabiv2
hexagon-unknown-linux-musl
i586-unknown-linux-gnu
i586-unknown-linux-musl
i686-linux-android
i686-unknown-linux-gnu
i686-unknown-linux-musl
loongarch64-unknown-linux-gnu
m68k-unknown-linux-gnu
mips-unknown-linux-gnu
mips-unknown-linux-musl
mips-unknown-linux-uclibc
mips64-openwrt-linux-musl
mips64-unknown-linux-gnuabi64
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-gnuabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-gnu
mipsel-unknown-linux-musl
mipsel-unknown-linux-uclibc
mipsisa32r6-unknown-linux-gnu
mipsisa32r6el-unknown-linux-gnu
mipsisa64r6-unknown-linux-gnuabi64
mipsisa64r6el-unknown-linux-gnuabi64
powerpc-unknown-linux-gnu
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-musl
powerpc64-unknown-linux-gnu
powerpc64-unknown-linux-musl
powerpc64le-unknown-linux-gnu
powerpc64le-unknown-linux-musl
riscv32gc-unknown-linux-gnu
riscv32gc-unknown-linux-musl
riscv64-linux-android
riscv64gc-unknown-linux-gnu
riscv64gc-unknown-linux-musl
s390x-unknown-linux-gnu
s390x-unknown-linux-musl
sparc-unknown-linux-gnu
sparc64-unknown-linux-gnu
thumbv7neon-linux-androideabi
thumbv7neon-unknown-linux-gnueabihf
thumbv7neon-unknown-linux-musleabihf
x86_64-linux-android
x86_64-unikraft-linux-musl
x86_64-unknown-linux-gnu
x86_64-unknown-linux-gnux32
x86_64-unknown-linux-musl
x86_64-unknown-linux-ohos

_______________________________________________
devel mailing list
devel at rtems.org<mailto: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/20240131/e37c1113/attachment-0001.htm>