Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel
Package: wnpp
Severity: wishlist
Owner: Adam Borowski <kilobyte@angband.pl>
* Package name : arch-detect
Upstream Author : me
* URL : https://github.com/kilobyte/arch-detect
* License : MIT
Programming Lang: mostly assembler
Description : detect architectures supported by your machine/kernel
This package lets you enumerate architectures that your kernel can run.
The check is for the ability to run machine code and supporting appropriate
syscall ABI -- you may need to install userland libraries in a chroot,
container or via multiarch to actually execute non-static binaries of such
architectures.
.
Architectures detected by this version of arch-detect are:
* amd64, i386, x32
* mips, mipsel, mips64, mips64el
* arm, armel, armhf, arm64
* powerpc, ppc64, ppc64el
* m68k
* sh4
* s390x
* sparc64
* illumos-amd64
* win32, win64
My reason here is that x32 can't be detected other than trying a syscall and
seeing if it fails. But then, we don't want a 344 byte package -- so here's
one that handles all release archs and most -ports ones. Most of these can
be detected by reading /proc and binfmts, but that's neither easy nor
reliable -- testing empirically works better.
Some quirks:
* ppc64el: I check "mtvsrd r0, r0" to fail qemu if it suffers from #813698
* armhf: "dmb" nicely SIGILLs on RPi 1, are there other ARMv7-but-not-armhf
in the wild worth checking?
* arm: untested (does anyone have that old hardware?) -- fails on all
porterboxes but succeeds on both kernel 3.8 on Odroid-U2 and 4.1 on
Raspbian RPI 1.
Archs that are missing:
* kfreebsd-*: no cross binutils in unstable (uses a different format, unlike
hurd and Solaris which share it with Linux)
* hurd: how do you even do syscalls there?!? Trying to figure it out
exhausted my attention span. RTFSing glibc, I see it's something bizarre:
_exit() requests some server to terminate the process then goes into an
endless loop of dividing 1/0.
* alpha: no machine to test it on, I'm reluctant to trust qemu exclusively
* hppa: no machine to test, not even supported by qemu
* ia64: no cross binutils
* sparc: binutils can multilib it, does anyone still want it?
* powerpcspe: no machine, debootstrap in qemu fails
Naming issues:
* illumos-amd64: (Solaris): dpkg's table has different names; I used this
one as it's an established unofficial port in a pretty good shape; you
may argue a different name though -- like, something that mentions that
this syscall ABI works on real Solaris...
* win32, win64: should I name them -i386, -amd64? Not sure if detecting
them even makes sense -- binfmts exist but you're not going to chroot/
multiarch those...
Reply to: