[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Feb 2024 04:31:00 -0600
From: Rob Landley <rob@...dley.net>
To: Linux-sh list <linux-sh@...r.kernel.org>, musl <musl@...ts.openwall.com>
Subject: FDPIC on sh4?
Is there any easy way to build FDPIC support for sh4 with-mmu? In theory ARM can
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'
Backstory: I want to test nommu under qemu, and my existing tests are all using
qemu-system-$TARGET builds with musl-libc toolchains built by musl-cross-make.
I have a nommu test environment on real (FPGA) hardware, using an sh2 fdpic
toolchain built from musl-cross-make using gcc 9.4.0, but that's not part of my
normal "cursor up and hit enter" fully automated regression testing that builds
and launches qemu instances with a prepared filesystem that launches tests from
the init script and does "expect" style processing on the serial console
connected to qemu's stdin/stdout.
Testing on the FPGA board requires repeatedly removing and inserting sd cards,
so I don't do it nearly as often, and right now that's my ONLY nommu test
environment.
I want to get a qemu-system-something running nommu. Since musl-libc only
supports fdpic, this limits my choices to the intersection of Linux's FDPIC support:
$ grep FDPIC -m1 -A3 fs/Kconfig.binfmt
config BINFMT_ELF_FDPIC
bool "Kernel support for FDPIC ELF binaries"
default y if !BINFMT_ELF
depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
And gcc's FDPIC support:
$ dirname $(grep -irl fdpic gcc/config) | sort -u
gcc/config/arm
gcc/config/bfin
gcc/config/frv
gcc/config/sh
Ever since linux threw blackfin and frv overboard to lighten the load, this
means gcc can produce fdpic output for exactly two targets that Linux supports:
arm and superh. (No, riscv is not joining them. I emailed about
https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/ZjYUJswknQ4/m/QnTEfur4BwAJ
yesterday and was told "Sadly that project didn't go beyond the ABI design
phase." so riscv-fdpic is _not_ currently in development.)
In theory arm can use the FDPIC loader on a with-mmu kernel, but the arm
configure doesn't have a way to combine "musl" with the magic
"uclinuxfdpiceabidoodahdoodah" blob because their matches keep looking like:
"arm*-*-uclinuxfdpiceabi" and "*-linux-musl*" which aren't compatible. (If that
first one didn't have the extra dash...) Alas arm-unknown-musl-uclinuxfdpiceabi
makes binutils go "checking target system type... Invalid configuration
`armv7m-linux-musl-uclinuxfdpiceabi': machine `armv7m-linux-musl' not recognized".
So I was thinking "maybe I can build an sh4 kernel with an sh4 compiler, and
build a userspace with the sh2eb compiler" (this is unlikely to work because
every sh4 system I've ever used is little endian and the j-core guys
inexplicably chose big endian, but I can burn that bridge when I come to it...)
But that's how I hit the "enabling FDPIC on with-mmu only works with arm,
nothing else" issue above. And that's incompatible with selecting musl support.
Rob
PS. the sh2 fdpic toolchain in musl-cross-make doesn't reproduce with the newest
"supported" gcc (11.2.0) because:
In file included from libstdc++-v3/libsupc++/eh_call.cc:32:
libstdc++-v3/../libgcc/unwind-pe.h: In function 'const unsigned char*
read_encoded_value_with_base(unsigned char, _Unwind_Ptr, const unsigned char*,
_Unwind_Ptr*)':
libstdc++-v3/../libgcc/unwind-pe.h:270:25: error: '_Unwind_gnu_Find_got' was not
declared in this scope
270 | result += _Unwind_gnu_Find_got ((_Unwind_Ptr) u);
Which has been broken ever since musl-cross-make's newest last commit almost 2
years ago.
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.
