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