[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08431a7c-322e-596c-ff46-6b7e0578646d@landley.net>
Date: Fri, 16 Feb 2024 06:25:44 -0600
From: Rob Landley <rob@...dley.net>
To: Rich Felker <dalias@...c.org>, Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Linux-sh list <linux-sh@...r.kernel.org>, musl <musl@...ts.openwall.com>
Subject: Re: FDPIC on sh4?
On 2/15/24 10:47, Rich Felker wrote:
> 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.
It's in arch/arm/kernel/elf.c, and pretty short. Doesn't LOOK
architecture-specific, although I'm not an expert. (Why SZ_16M instead of
RLIM_STACK? No idea...)
#if defined(CONFIG_MMU) && defined(CONFIG_BINFMT_ELF_FDPIC)
void elf_fdpic_arch_lay_out_mm(struct elf_fdpic_params *exec_params,
struct elf_fdpic_params *interp_params,
unsigned long *start_stack,
unsigned long *start_brk)
{
elf_set_personality(&exec_params->hdr);
exec_params->load_addr = 0x8000;
interp_params->load_addr = ELF_ET_DYN_BASE;
*start_stack = TASK_SIZE - SZ_16M;
if ((exec_params->flags & ELF_FDPIC_FLAG_ARRANGEMENT) ==
ELF_FDPIC_FLAG_INDEPENDENT) {
exec_params->flags &= ~ELF_FDPIC_FLAG_ARRANGEMENT;
exec_params->flags |= ELF_FDPIC_FLAG_CONSTDISP;
}
}
#endif
Oddly, it's NOT in arch/arm64. Does the 64 bit arch pull in bits of the 32 bit
one, or is this only supported for 32 bit arm?
Rob
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.
