native64: Separate board for 64-bit native

[fzi-haxel]

Contribution description

Adds a separate board for native64 instead of the NATIVE_64BIT workaround from #20315.

boards/native64 more or less just includes the files from board/native (similar to the openlabs-kw41z-mini-256kib board).
The main logic for native is still in cpu/native and boards/native.

The bulk of the changes are related to the build and tests checks for the native board. For example

Filetype	Before	After
C	#ifdef BOARD_NATIVE	#ifdef CPU_NATIVE
Makefile	ifeq ($(BOARD),native)	ifneq (,$(filter native native64,$(BOARD)))
Python	if BOARD == "native":	if BOARD in ["native", "native64"]:

Changes to the CI

The last commit makes some changes to the CI to test native64 in the same way as native.
Note: The CI docker may be missing some dependencies, such as libsdl2-dev for 64 bit.

Testing procedure

The board should behave just like the native board, except that it lacks Rust support.
The following command compiles and tests the same examples and tests as native (with the exception of the Rust-based ones).

• ./dist/tools/compile_and_test_for_board/compile_and_test_for_board.py . native64.

[riot-ci]

Murdock results

✔️ PASSED

d1f1f8a sys/psa_crypto: Use PRIuSIZE in debug messages

Success	Failures	Total	Runtime
10016	0	10016	12m:18s

Artifacts

• Documentation preview

[benpicco]

/usr/include/SDL2/SDL_config.h:4:10: fatal error: SDL2/_real_SDL_config.h: No such file or directory
    4 | #include <SDL2/_real_SDL_config.h>

looks like we also need to install the 64 bit version of that on CI

[fzi-haxel]

/usr/include/SDL2/SDL_config.h:4:10: fatal error: SDL2/_real_SDL_config.h: No such file or directory
    4 | #include <SDL2/_real_SDL_config.h>

looks like we also need to install the 64 bit version of that on CI

I created RIOT-OS/riotdocker#241
Alternatively, we could blacklist them for native64.

[fzi-haxel]

All tests seem to work on my machine. However, four tests fail sporadically on the CI (especially the LLVM builds).
I think most (maybe all) of them are stack overflows. native64 uses more stack than native, e.g. during printing (~1kB) or during thread switching, but since the native stacks are quite large, I never had to touch them.

I created a fixup for the problematic tests

• tests/core/thread_priority_inversion: Bigger main thread stack -> still fails sometimes
• tests/sys/sema_inv: Bigger test threads
• tests/net/gnrc_netif_ieee802154: Bigger SOCKET_ZEP_MAC_STACKSIZE (this could be problematic, but it's hard to test as I can't reproduce it) -> still fails sometimes
• tests/periph/timer_periodic: Fails sometimes with _native_popsig: real_read: Bad file descriptor, may still be the effect of a stack overflow. But again, can't test it locally. For now, I just blacklisted it for the CI.

If you have any ideas how to fix them or how to reproduce the failures locally, I'm all ears.

[benpicco]

Since the riotdocker CI issue doesn't seem to be so easy to solve, I'd suggest you just blacklist the native64 board on the affected tests.

[fzi-haxel]

Since the riotdocker CI issue doesn't seem to be so easy to solve, I'd suggest you just blacklist the native64 board on the affected tests.

I blacklisted the tests.

I also increased the default stacksize for native64 instead of adding exceptions for the LLVM tests that sometimes fail.
But SOCKET_ZEP_MAC_STACKSIZE is probably still a problem.

[chrysn]

Is having separate boards the right abstraction here? Seeing that some of the ESP32 have a single board take an extra parameter to switch the precise chip (may be different CPUs) IIUC, maybe that's the more accurate abstraction. After all, what matters to users of native (at least to me) is not so much how it is compiled, but more that the network is tun/tap backed, MTD comes from a local file and so on.

What's the motivation behind having two separate boards?

[benpicco]

What's the motivation behind having two separate boards?

• ease of use
• CI coverage

[benpicco]

That's getting much nicer

[chrysn]

* ease of use

I'd think ease of use would be best if the 64bit version of native would just become the default -- and for examples that have BOARD=native, setting some detail flag is just as usable as changing the board. (And neither is immediately discoverable to users who have used native for some time).

* CI coverage

That's true but should be fixable just as easily in our CI -- without introducing a board variant.

I'll leave it at that, given that I don't contribute much to this port otherwise, but will ping the matrix room in case anyone wants to present more solid points than my gut feeling "this is the wrong way to do it".

[edit after some clarifying chat]: I misremembered the ESP32 part, and there is precedent for board variants over subtleties. Any remaining concerns of mine are better spent around cleaning up board inheritance and defining boards more clearly.

[benpicco]

Please squash

[benpicco]

Hmm the timer tests are failing a bit too consistently on CI for native64 - maybe something is broken there.

[benpicco]

Yup, that fixed it - Please squash

[fzi-haxel]

Hmm the timer tests are failing a bit too consistently on CI for native64 - maybe something is broken there.

I think I found it. I increased the native isr stacksize

• char __isr_stack[SIGSTKSZ] -> char __isr_stack[THREAD_STACKSIZE_DEFAULT]. (So same size for native and double for native64).

I try a few CI runs to see if it fails. But it's still a mystery why I can't reproduce it.
It only happens sometimes on the CI, only in threads with printf and only for LLVM builds.

[fzi-haxel]

Yup, that fixed it - Please squash

Done