[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: