Hm. Somehow Outlook botched the inline quotes of the html mail. Does it work now?
Von: Joel Sherrill <j...@rtems.org> Gesendet: Mittwoch, 31. Januar 2024 16:57 An: Karel Gardas <karel@functional.vision> Cc: Frank Kühndel <frank.kuehn...@embedded-brains.de>; Sommer, Jan <jan.som...@dlr.de>; devel@rtems.org Betreff: Re: Naming convention for Rust target platforms On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas <karel@functional.vision<mailto:karel@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@rtems.org<mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
