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

[Rob Landley <rob@landley.net>]

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