|
|
Message-ID: <49c8fa8d-edf5-4f21-8676-1fb8b34af710@landley.net>
Date: Mon, 4 Nov 2024 02:10:32 -0600
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
かがやくひかり <1486864380@...com>
Subject: Re: Does musl support FDPIC on targets other than SH?
On 11/3/24 19:01, Rich Felker wrote:
> On Sun, Nov 03, 2024 at 03:52:31PM +0800, かがやくひかり wrote:
>> Does musl support FDPIC on targets other than SH, for example on ARM?
>
> At present, no, but the FDPIC implementation in musl is pretty much
> entirely arch-agnostic. Upstream GCC ARM-FDPIC introduced some bugs
> that need to be fixed, but that's not too hard, and if I remember
> right there's a work-in-progress ARM-FDPIC port for musl that could be
> polished up and merged if someone has the interest to help test and
> address any open questions/problems.
I'm interested in following this work if you have pointers. I tried to
get arm fdpic to do something useful a few months back and couldn't, and
unfortunately sh and arm are the only two targets that gcc and the linux
kernel currently both (claim to) support fdpic for:
https://lists.gnu.org/archive/html/qemu-devel/2024-10/msg05476.html
Alas, every other nommu target in buildroot or
https://github.com/gregungerer/simple-linux uses PIE binaries, which
scale terribly on nommu.
On the gcc side searching for "fdpic" in gcc/config/* hits arm, sh, frv,
and blackfin, but support for those last two architectures was removed
from Linux due to lack of maintainers in 2018.
On the linux side linux/fs/Kconfig.binfmt has:
config BINFMT_ELF_FDPIC
bool "Kernel support for FDPIC ELF binaries"
default y if !BINFMT_ELF
depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
Which SEEMS to give 3 more options, but I can't find a compiler for any
of them.
I can build the fdpic loader for m68k (if I disable nommu support), but
it's just a way of loading PIE binaries on nommu, there's no fdpic
compiler for m68k:
https://www.spinics.net/lists/linux-m68k/msg24781.html
I could try to give xtensa a go, I've been vaguely following their
out-of-tree musl support since they got it working in 2016 and
https://www.openwall.com/lists/musl/2024/05/06/7 presumably applies to
current, but again I dunno where to get a compiler, and whether they
actually have proper fdpic support rather than just PIE. (Where are the
extra registers to hold the separate segment bases defined in the loader
arch code?)
Last I heard the riscy people were removing nommu support from that
architecture entirely, ala
https://lore.kernel.org/linux-riscv/20240226140649.293254-1-cleger@rivosinc.com/
but I don't know if they actually went through with it. I haven't been
following it closely because I can't bring myself to care about open
source doing its own itanium, but a lot of other people do...
(It's possible some architectures are still using binflt, which I still
think of as a.out for nommu, but I haven't made the bolt-on elf2flt
converter work in years...)
Rob
P.S. My patch to use the fdpic loader on arch/sh with MMU enabled like
ARM can is
https://landley.net/bin/mkroot/latest/linux-patches/0002-sh4-fdpic.patch
which allows testing an fdpic userspace under qemu-system-sh4. Rich said
you don't need it, but never explained how. The regular ELF loader could
not run fdpic binaries when I tried it, and it wouldn't exercise the
fdpic loader codepath anyway (separately distributing the segments). I'm
all for someday merging fs/binfmt_elf.c and fs/binfmt_elf_fdpic.c like
ext2/3/4 got merged into one driver, but that's not the kernel that's
shipping today...
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.