On 10/24/24 03:27, Thomas Huth wrote:
Now that we are aware of binaries that are available for sh4eb,
we should make sure that there are no regressions with this
target and test it regularly in our CI.
Any progress on restoring this? Didn't see it in "git pull" just now...
+class R2dEBTest(LinuxKernelTest):
+
+ ASSET_TGZ = Asset(
+ 'https://landley.net/bin/mkroot/0.8.11/sh4eb.tgz',
+ 'be8c6cb5aef8406899dc5aa5e22b6aa45840eb886cdd3ced51555c10577ada2c')
Feel free to pull binaries from my site, but from a reliability
perspective "some random dude got hit by a bus so a site went down that
broke our test infrastructure" seems a bit dodgy. (Even the Internet
Archive has been having reliability issues of late, and "as long as
Brewster Kahle's dot-com money holds out" seems a similar bus number.)
Building it yourself from source seems more reliable. Is there any sort
of policy here?
I build the toolchains, kernel, and userspace entirely from source and
can provide the reproduction sequences for those if you like.
It's part of my mkroot project, which is attempting to build small qemu
systems for every target supported by all of:
1) qemu
2) linux
3) musl-libc
4) gcc
And even do automated smoketests on them showing it can boot, run a
shell script, and access a virtual block device and network connection:
https://github.com/landley/toybox/blob/master/mkroot/testroot.sh
Alas a lot of targets I would LIKE to support are missing something in
one or more of those 4 packages. (No sparc in musl, etc.)
At the moment this lack is most obvious to me for nommu support. If I
want fdpic then linux/fs/Kconfig.binfmt says my options are:
config BINFMT_ELF_FDPIC
bool "Kernel support for FDPIC ELF binaries"
default y if !BINFMT_ELF
depends on ARM || ((M68K || RISCV || SUPERH || XTENSA) && !MMU)
But gcc's source says my options are:
$ grep -lir fdpic gcc/config | xargs dirname | uniq
gcc/config/frv
gcc/config/sh
gcc/config/bfin
gcc/config/arm
Which is exactly TWO targets that overlap. (There were two more, but
Linux commit f5a8eb632b56 removed bfin and frv in 2018, and while I've
followed arm-fdpic development since 2016 I have yet to get it to work
for me.)
(NOMMU support is a bit like eukaryote cells in biology: beneath most
people's notice but EVERYWHERE, to the point that ecosystem physically
outweighs the "more advanced" one if you add up each instance of both.)
While you can do PIE binaries on nommu (which is what buildroot and
Buildroot and https://github.com/gregungerer/simple-linux do for the
other nommu architectures), that just doesn't scale. If you run two PIE
instances of "bash" on nommu it loads two copies of the bash binary into
memory, AND each one requires one big contiguous block of memory for the
text, rodata, bss, and data segments all together.
The point of fdpic is those four segments relocate independently, so
multiple instances of the same program can share text and rodata, and
also use smaller chunks of memory for bss and data which is much easier
to come by in system without an mmu to let virtual mappings collate
fragmented physical memory. On nommu memory fragmentation is basically
inevitable.
Rob
P.S. In theory I could try linux's nolibc.h instead of musl but building
toybox under that is quite the lift, and I briefly had an llvm hexagon
build working instead of gcc (copied from your test stuff, but
https://compiler-rt.llvm.org/ is just apocalyptically badly designed
that the easy way to get a portable build out of it honestly seems to be
to write a new replacement library from scratch).
