Re: [musl] Does musl support FDPIC on targets other than SH?

[enh <enh@google.com>]

On Mon, Nov 4, 2024 at 3:10 AM Rob Landley <rob@landley.net> wrote:
>
> 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.

riscv fdpic came up on in the psabi sig meetings a couple of times,
but it wasn't obvious to me that anyone actually directly cared/needed
it versus "arm32 sort-of has this, so someone might want it for rv32
too, maybe?".

> 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...