[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240215164723.GG4163@brightrain.aerifal.cx>
Date: Thu, 15 Feb 2024 11:47:23 -0500
From: Rich Felker <dalias@...c.org>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Rob Landley <rob@...dley.net>, Linux-sh list <linux-sh@...r.kernel.org>,
musl <musl@...ts.openwall.com>
Subject: Re: 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 <dalias@...c.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
