From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id B0426241B6 for ; Thu, 15 Feb 2024 14:49:39 +0100 (CET) Received: (qmail 1462 invoked by uid 550); 15 Feb 2024 13:46:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1409 invoked from network); 15 Feb 2024 13:46:32 -0000 Date: Thu, 15 Feb 2024 08:49:41 -0500 From: Rich Felker To: Rob Landley Cc: Linux-sh list , musl Message-ID: <20240215134941.GE4163@brightrain.aerifal.cx> References: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] FDPIC on sh4? On Thu, Feb 15, 2024 at 04:31:00AM -0600, Rob Landley wrote: > Is there any easy way to build FDPIC support for sh4 with-mmu? In theory ARM can On the userspace toolchain and musl side, yes, I see no reason you shouldn't be able to build musl for sh4 with fdpic ABI or build a toolchain for sh4 that defaults to fdpic and has fdpic target-libs. I just tested passing -mfdpic to sh4-linux-musl-gcc and it seems to produce correct fdpic code. On the kernel side, I'm not sure, but the normal ELF loader should be able to load fdpic binaries on a system with mmu. It will not float the data segment separately from text, but doesn't need to because it has an mmu. If this is no longer working it's a kernel regression; that's how I always tested sh2eb fdpic binaries on qemu-system-sh4eb. > do it, so I tried editing the kconfig BINFMT_ELF_FDPIC dependencies in > fs/Kconfig.binfmt to move "SUPERH" out of the !MMU list and put it next to ARM, > switched on the FDPIC loader, and the build broke with: > > fs/binfmt_elf_fdpic.o: in function `load_elf_fdpic_binary': > binfmt_elf_fdpic.c:(.text+0x1b44): undefined reference to > `elf_fdpic_arch_lay_out_mm' It looks like there's an arch-provided function that's conditional on !MMU in arch/sh but that, now that fdpic loader is intended to be supported on mmu-ful systems, should be changed to be conditional on fdpic support (or maybe even unconditional if fdpic can be loaded as a module). Just look for where it's defined in arch/sh. If it's in a nommu-specific file it might need to be moved somewhere more appropriate, or an mmu-ful variant may need to be written and placed somewhere more appropriate. > Backstory: I want to test nommu under qemu, and my existing tests are all using > qemu-system-$TARGET builds with musl-libc toolchains built by musl-cross-make. > > I have a nommu test environment on real (FPGA) hardware, using an sh2 fdpic > toolchain built from musl-cross-make using gcc 9.4.0, but that's not part of my > normal "cursor up and hit enter" fully automated regression testing that builds > and launches qemu instances with a prepared filesystem that launches tests from > the init script and does "expect" style processing on the serial console > connected to qemu's stdin/stdout. > > Testing on the FPGA board requires repeatedly removing and inserting sd cards, > so I don't do it nearly as often, and right now that's my ONLY nommu test > environment. > > I want to get a qemu-system-something running nommu. Since musl-libc only > supports fdpic, this limits my choices to the intersection of Linux's FDPIC support: musl also supports non-fdpic ELF just fine on nommu, but it has to be fully position independent (PIE) and of course does not get shareable text. But this is usable for testing. > $ grep FDPIC -m1 -A3 fs/Kconfig.binfmt > config BINFMT_ELF_FDPIC > bool "Kernel support for FDPIC ELF binaries" > default y if !BINFMT_ELF > depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU) > > And gcc's FDPIC support: > > $ dirname $(grep -irl fdpic gcc/config) | sort -u > gcc/config/arm > gcc/config/bfin > gcc/config/frv > gcc/config/sh > > Ever since linux threw blackfin and frv overboard to lighten the load, this > means gcc can produce fdpic output for exactly two targets that Linux supports: > arm and superh. (No, riscv is not joining them. I emailed about > https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/QnTEfur4BwAJ > yesterday and was told "Sadly that project didn't go beyond the ABI design > phase." so riscv-fdpic is _not_ currently in development.) > > In theory arm can use the FDPIC loader on a with-mmu kernel, but the arm > configure doesn't have a way to combine "musl" with the magic > "uclinuxfdpiceabidoodahdoodah" blob because their matches keep looking like: > "arm*-*-uclinuxfdpiceabi" and "*-linux-musl*" which aren't compatible. (If that > first one didn't have the extra dash...) Alas arm-unknown-musl-uclinuxfdpiceabi > makes binutils go "checking target system type... Invalid configuration > `armv7m-linux-musl-uclinuxfdpiceabi': machine `armv7m-linux-musl' not recognized". > > So I was thinking "maybe I can build an sh4 kernel with an sh4 compiler, and > build a userspace with the sh2eb compiler" (this is unlikely to work because > every sh4 system I've ever used is little endian and the j-core guys > inexplicably chose big endian, but I can burn that bridge when I come to it...) > But that's how I hit the "enabling FDPIC on with-mmu only works with arm, > nothing else" issue above. And that's incompatible with selecting musl support. > > Rob > > PS. the sh2 fdpic toolchain in musl-cross-make doesn't reproduce with the newest > "supported" gcc (11.2.0) because: > > In file included from libstdc++-v3/libsupc++/eh_call.cc:32: > libstdc++-v3/../libgcc/unwind-pe.h: In function 'const unsigned char* > read_encoded_value_with_base(unsigned char, _Unwind_Ptr, const unsigned char*, > _Unwind_Ptr*)': > libstdc++-v3/../libgcc/unwind-pe.h:270:25: error: '_Unwind_gnu_Find_got' was not > declared in this scope > 270 | result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u); > > Which has been broken ever since musl-cross-make's newest last commit almost 2 > years ago. Could you file a bug report for this? I think it's actually a GCC regression but I'm not sure, so there probably needs to be a report on the GCC tracker. Rich