Stop shipping ARM32 builds for releases? #32375

Clearly there is no hurry here. This is more of a brainstorming issue than a proposal.

For:

• 64-bit ARM is the standard nowadays for the type of computing hardware our users tend to have (modern Raspberry Pi's and ARM servers). While 32-bit ARM is only still used in low-power embedded systems, an unlikely combination with a bitcoin node.

• 32-bit ARM is the last 32-bit architecture that we ship releases for. After removing this, we could fully focus on optimizing for large virtual address spaces. This means nearly-unrestricted mmap, and no need to worry about the virtual memory overhead of more thread stacks.

• Is it still being properly tested at all? If no one really cares, things could break without us noticing.

Against:

• There are likely still users that use 2010-era ARM boxes for their nodes, though the number is likely to be dwindling (mine certainly died by now).

• Requiring 64-bit even for self-built binaries is a step further, it might be wise to keep the 32-bit door open, at least i'm always hesitant with anything that limits potential hardware that can be used for bitcoin nodes.

  • OTOH we'd be in good company. Monero never supported 32-bit platforms for their node (because of using lmdb).

See also bitcoin-core/bitcoincore.org#1126, where the default was recently changed to 64-bit.

IIRC, Raspberry Pi OS only started shipping 64-bit OSes a couple of years ago. For a while, you could buy a Pi 3 or 4 which had 64-bit hardware but the available Raspberry Pi OS image was only 32-bit. I would imagine that several of these machines are probably still in use. It also seems like the 32-bit images are still prominently shown on their website so I think it may be a bit premature to stop shipping 32-bit?

I think I heard that that the Pi 5 ARM chips are unable to boot a 32bit kernel (although you can still hack about in a 32 bit userspace if you really want), so it seems that the day is definitely getting nearer.

If I am correct above the question then perhaps becomes "how long do we want to ship release builds for Pi 3's and 4's".

If this is dropped in the future, I guess we'll wholesale drop support for 32-bit architectures? If there is no release 32-bit build that we feel like is worth keeping, then I wonder if it is worth it to check and support it in CI.

As mentioned before, 32 bit support isn't tested as thoroughly as 64 (e.g. https://github.com/bitcoin/bitcoin/pull/28531/files#r2036954366), it would simplify a few scenarios if we didn't have walk on eggshells when doing storage size calculations (e.g. https://github.com/bitcoin/bitcoin/blob/master/src/util/byte_units.h#L15)

IIRC, Raspberry Pi OS only started shipping 64-bit OSes a couple of years ago. For a while, you could buy a Pi 3 or 4 which had 64-bit hardware but the available Raspberry Pi OS image was only 32-bit. I would imagine that several of these machines are probably still in use. It also seems like the 32-bit images are still prominently shown on their website so I think it may be a bit premature to stop shipping 32-bit?

Agree, there's no hurry.

I think I heard that that the Pi 5 ARM chips are unable to boot a 32bit kernel (although you can still hack about in a 32 bit userspace if you really want), so it seems that the day is definitely getting nearer.

Correct, it's more complicated for ARM than for x86*, but broadly modern 64-bit SoCs don't support 32-bit kernels. Most (but not all) do support 32-bit user-space, but there's less compatibility legacy to warrant keeping even that circuitry.

Performance-wise, using 32-bit applications on hardware that supports 64-bit ARM is a really bad idea, and should be discouraged.

* See "AArch32" column here https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-socs.html

I think the main issue is that there is no supported way to run the integer sanitizer on armhf. Running the clang integer sanitizer is essential, because on 32-bit architectures, size_t is only u32. A harmless-looking calculation like size_t{450_MiB}*10/100 will give a different result on different architectures.

See the related commits: like 3789215f73466606eb111714f596a2a5e9bb1933, ac76d94117be70d2dcc23ba34b120b44aeb3b0c1, or 28a523fb94d333fd8a28ca101cce746157a90fb6 ...

In theory one could use the i386 integer sanitizer as a proxy, but this is tedious, because one has to work around a bunch of irrelevant warnings about -D_TIME_BITS=64 missing or irrelevant warnings about not using fseeko/ftello.

I am not saying that removal should be rushed, but I think we should acknowledge that a lot less quality assurance is happening on armhf.

Another (small) note; 32 bit arm builds also don't have static PIE support on our current glibc version (although it should be in 2.44 according to this comment). Having to support old platforms like arm32 (and ppc64) will naturally hamper our ability to make beneficial changes (like -static-pie) occasionally, for arguably little benefit, as their support gets poorer and poorer.