This tool will tell you "can your machine+kernel run architecture X?".

The check is for the ability to run machine code and supporting appropriate
syscall ABI, not for the presence of userland libraries.  Ie, a positive
answer means you can use a chroot or container of that architecture, add it
to your multiarch set, etc, but doesn't mean you can currently run non-static
binaries without installing required libraries.

Architectures detected by this version of arch-test are:
 * amd64, i386, x32
 * mips, mipsel, mipsn32, mipsn32el, mips64, mips64el
 * arm, armel, armhf, arm64, arm64ilp32
 * powerpc, ppc64, ppc64el, powerpcspe
 * m68k
 * sh4
 * s390x
 * sparc, sparc64
 * illumos-amd64
 * win32, win64
 * kfreebsd-amd64, kfreebsd-i386
 * alpha
 * hppa
 * ia64
 * riscv32, riscv64
 * loong64


Detection quirks
================

This tool claims FreeBSD with its Linux emulation layer on can't run i386.
That's not a bug -- it can't run _unmodified_ i386 binaries.  There's a
tool "brandelf" that sets field 0x7 in the ELF header, required by FreeBSD
but not set by Linux nor Solaris toolchains.

Emulation of the SWP instruction on at least Odroid-U2 vendor kernel is
broken, subtly breaking armel processes.  They mostly work but once there's
lock contention, shit will happen.  Thus, it's debatable whether to mark
armel as unsupported there -- I do so only because it's easier for me.


Adding new archs
================

Helper programs are supposed to write the string "ok\n" to stdout then
return exit code 0.  This can be done by statically compiling "generic.c"
for the given architecture.  Unfortunately, doing so with glibc produces
~800KB executables which multiplied by the number of archs to test would
take too much space for such a minor tool.

And, for non-baseline archs some specific code is needed.  Examples:
* ppc64el requires POWER8, some versions of qemu-user can run little-endian
  PPC64 but lack some instructions required by the Debian arch.
* powerpcspe has no classic FPU but a bunch of other instructions.
* armhf uses same syscall ABI as armel.

One way to ascertain required support is trying to run an unprivileged
instruction that's lacking on older versions of the ISA.  This causes the
helper program to fail with SIGILL/SIGFPE/etc which means it will return
an exit code other than 0.


Missing Debian architectures
============================

* hurd-*: it has no proper syscalls, the equivalent being complicated RPC
  calls implemented inside glibc.  This is similar to Windows where the real
  syscalls (NT) are undocumented and unstable while everyone is supposed to
  link to "kernel" shared libraries.
  Unfortunately for hurd, there's no cross toolchain in Debian, unlike mingw.


Non-Debian architectures
========================

While currently arch-test is heavily biased towards Debian, there is no
reason for it to stay so.  I would need to compile the assembler from source
during the build, but that's doable.  All that's needed is motivation (ie,
tell me if you have a use) and access to test machines.


elf-arch
========

Another tool in this package answers "what arch this program/library is
for?".  Alas, it is impossible to determine this accurately, and in many
cases this program will give only a vague architecture family.  Known
variants of such a family are thus considered "aliases", and you can query
whether the given executable matches a set.

Besides all archs known by arch-test, elf-arch also knows about hppa64 and
mipsr6 variants.


Resources
=========

man 2 syscall
https://github.com/deater/ll_asm.git