Naming convention for Rust target platforms

[Joel Sherrill]

On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas <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.

>
>
> 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
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240131/f2c7803e/attachment.htm>