On Wed, Jan 31, 2024 at 12:31 AM Karel Gardas <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. > > > 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 > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel