RFC: Improving testing under the remaining supported 32 bit platforms

practicalswift commented at 4:41 pm on May 26, 2019: contributor

The Windows 32 bit build was recently removed:

#15939: gitian: Remove Windows 32 bit build

This leaves us with the following supported 32 bit platforms:

arm-linux-gnueabihf (compiled in Travis)
i686-pc-linux-gnu (compiled and tested in Travis)

As the number of developers testing on these platforms decrease the probability of errors due to incorrect assumptions about sizeof(size_t), sizeof(time_t) and sizeof(long) is likely to increase.

Additionally we risk incorrectly assuming that reported errors on said platforms are 32 bit only bugs: the recent GCC miscompilation issue would likely have been identified much faster if it wasn’t thought to be “merely” an i686-pc-linux-gnu issue for the first six months after being reported (see history in #14580: 32-bit test failure: test/crypto_tests.cpp).

Questions:

What can be done to improve testing under these platforms until we drop support?
In which order do we envision dropping support for the mentioned platforms?

fanquake added the label Brainstorming on May 26, 2019

fanquake added the label Tests on May 26, 2019

MarcoFalke commented at 8:27 pm on May 28, 2019: member

arm-linux-gnueabihf (not tested in Travis)

This is compiled in travis, but the tests aren’t run. If there is a way to run them, lets do it. Also, lets hope that users run the tests themselves before running Bitcoin Core whether they are run on travis or not.

riscv32-linux-gnu (tested in Travis, but is it a platform we plan to provide binaries for?)

this is not tested in travis at all. I hope that users that compile from source run the tests before running Bitcoin Core.

practicalswift commented at 1:34 pm on May 30, 2019: contributor

FWIW, a fresh sizeof(time_t) assumption example: #16117 (comment).

practicalswift commented at 1:58 pm on May 30, 2019: contributor

arm-linux-gnueabihf (not tested in Travis)

This is compiled in travis, but the tests aren’t run.

Thanks! Should have been “compiled in Travis”. OP updated.

riscv32-linux-gnu (tested in Travis, but is it a platform we plan to provide binaries for?)

this is not tested in travis at all.

Oh, good point. I mixed up things. Removed from OP.

That leaves us with arm-linux-gnueabihf and i686-pc-linux-gnu being the only “officially supported” 32-bit platforms? Am I missing some platform?

laanwj commented at 3:17 pm on May 30, 2019: member

riscv32-linux-gnu (tested in Travis, but is it a platform we plan to provide binaries for?)

IMO, 32 bit RISC-V is not worth supporting. I don’t expect anyone is going to make 32-bit RISC-V chips that are powerful enough to run a node. Even something like the low-end Kendryte K210 is 64 bit (and that’s too slow and can address too little physical memory to run a node).

I still test ARM32 often though.

practicalswift commented at 9:34 pm on May 30, 2019: contributor

IMO, 32 bit RISC-V is not worth supporting. I don’t expect anyone is going to make 32-bit RISC-V chips that are powerful enough to run a node.

Thanks for clarifying.

Please note the following mention of riscv32-linux-gnu which sounds incorrect? :-)

 0$ git grep -B7 -A2 riscv32-linux-gnu
 1depends/README.md-
 2depends/README.md-Common `host-platform-triplets` for cross compilation are:
 3depends/README.md-
 4depends/README.md-- `x86_64-w64-mingw32` for Win64
 5depends/README.md-- `x86_64-apple-darwin14` for macOS
 6depends/README.md-- `arm-linux-gnueabihf` for Linux ARM 32 bit
 7depends/README.md-- `aarch64-linux-gnu` for Linux ARM 64 bit
 8depends/README.md:- `riscv32-linux-gnu` for Linux RISC-V 32 bit
 9depends/README.md-- `riscv64-linux-gnu` for Linux RISC-V 64 bit
10depends/README.md-

MarcoFalke commented at 8:02 pm on June 10, 2019: member

I don’t really know how popular 32 bit is on linux. I guess the generic i686-pc-linux-gnu can be removed (similar to how ubuntu removed the 32 bit build). What about arm 32 bit?

MarcoFalke commented at 4:44 pm on June 19, 2019: member

https://lists.ubuntu.com/archives/ubuntu-devel-announce/2019-June/001261.html

GreenReaper commented at 11:34 pm on July 1, 2019: none

the recent GCC miscompilation issue would likely have been identified much faster if it wasn’t thought to be “merely” an i686-pc-linux-gnu issue for the first six months after being reported

I’d look at it this way: if it’d been given the same attention, a bug might have been fixed six months before it started appearing on configurations you really care about, because it wasn’t reproduced on 64-bit until then.

It’s a great reason to keep officially supported and tested 32-bit versions, otherwise you risk missing bugs that “happen to work” on officially-supported 64-bit platforms - or, more accurately, are not visibly broken with the current combination of OS/compiler/day-of-week. Stress situations are more likely to occur as well (maybe that is a negative in some ways, but a positive in others).

It strikes me as relatively easy to test on i686-pc-linux-gnu if you’re doing 64-bit as well; you can at least use the same hardware (not sure if there is the same level of backwards-compatibility for all ARM platforms).

hebasto commented at 8:25 am on July 16, 2019: member

@MarcoFalke

What about arm 32 bit?

Many of single-board computer based home nodes are 32-bit.

laanwj commented at 3:24 pm on November 18, 2019: member

FWIW I still use bitcoin core on ARM 32-bit. I don’t care about pre-built binaries, but I’d assume there’s more people still using i.MX6 era single-board computers for nodes. It’s much shorter ago than when x86_32 was a relevant platform. Agree with removing that.

Please note the following mention of riscv32-linux-gnu which sounds incorrect? :-)

Feel free to remove that mention. RISCV 32-bit has turned out to an irrelevant platform for Linux, all focus is on RV64 and possibly RV128 in the future.

MarcoFalke commented at 3:34 pm on November 18, 2019: member

It is also not possible to cross-compile to i686 from any non-x86 hardware because ubuntu does not provide the required packages for aarch64 for example: https://packages.ubuntu.com/bionic/g++-multilib

MarcoFalke closed this on Apr 27, 2020

DrahtBot locked this on Feb 15, 2022

RFC: Improving testing under the remaining supported 32 bit platforms #16096