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 53F5523DD5 for ; Thu, 15 Feb 2024 17:47:20 +0100 (CET) Received: (qmail 23697 invoked by uid 550); 15 Feb 2024 16:44:13 -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 23664 invoked from network); 15 Feb 2024 16:44:13 -0000 Date: Thu, 15 Feb 2024 11:47:23 -0500 From: Rich Felker To: Geert Uytterhoeven Cc: Rob Landley , Linux-sh list , musl Message-ID: <20240215164723.GG4163@brightrain.aerifal.cx> References: <2d8878fa-c990-e187-9040-934cce908e7c@landley.net> <20240215134941.GE4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] FDPIC on sh4? On Thu, Feb 15, 2024 at 03:53:53PM +0100, Geert Uytterhoeven wrote: > Hi Rich, > > On Thu, Feb 15, 2024 at 2:49 PM Rich Felker wrote: > > 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. > > ARM is the sole architecture that provides elf_fdpic_arch_lay_out_mm(). Ah, I missed that this was a new mmu-ful only function. So I guess something like the ARM one is needed. I'm not clear why this is expected to be arch-specific, so it would probably be nice for the kernel to provide a generic version that archs can use unless they need specific behaviors here, or just make it conditional whether it's called at all (only if the arch declares its presence) and use defaults otherwise. Rich