picolibc: FPU issue on x86 with timer_behavior test

[teburd]

Describe the bug
@golowanow noted that a test case (timer_behavior) was failing on an x86 hardware platform with an FPU exception.

Re-running this test on qemu_x86 shows the same exception.

To Reproduce
Comment out the platform_type lines in tests/kernel/timer/timer_behavior/testcase.yaml

Run west
west twister -p qemu_x86 -T tests/kernel/timer/timer_behavior -vvv

Expected behavior
A non failing test case, or at least one that doesn't cause a hardware exception over FPU usage

Logs and console output

DEBUG   - run test: qemu_x86/tests/kernel/timer/timer_behavior/kernel.timer.timer
DEBUG   - Spawning QEMUHandler Thread for qemu_x86/tests/kernel/timer/timer_behavior/kernel.timer.timer
DEBUG   - Running qemu_x86/tests/kernel/timer/timer_behavior/kernel.timer.timer (qemu)
DEBUG   - Spawning QEMUHandler Thread for qemu_x86/tests/kernel/timer/timer_behavior/kernel.timer.timer
DEBUG   - QEMU (136691): SeaBIOS (version zephyr-v1.0.0-0-g31d4e0e-dirty-20200714_234759-fv-az50-zephyr)
DEBUG   - QEMU (136691): Booting from ROM..
DEBUG   - QEMU (136691): *** Booting Zephyr OS build zephyr-v3.4.0-3252-gf0daf904bb02 ***
DEBUG   - QEMU (136691): Running TESTSUITE timer_jitter_drift
DEBUG   - QEMU (136691): ===================================================================
DEBUG   - QEMU (136691): START - test_jitter_drift_timer_period
DEBUG   - QEMU (136691): periodic timer behavior test using built-in restart mechanism
DEBUG   - QEMU (136691): collecting time samples for approx 100 seconds
DEBUG   - QEMU (136691): periodic timer samples gathered, calculating statistics
DEBUG   - QEMU (136691): E: Floating point unit device not available
DEBUG   - QEMU (136691): E: EAX: 0x05f4732e, EBX: 0x019e7c6d, ECX: 0x00000000, EDX: 0x02fa3997
DEBUG   - QEMU (136691): E: ESI: 0x033cf8d9, EDI: 0x033cf8da, EBP: 0x001286e4, ESP: 0x001286d4
DEBUG   - QEMU (136691): E: EFLAGS: 0x00000206 CS: 0x0008 CR3: 0x00138000
DEBUG   - QEMU (136691): E: call trace:
DEBUG   - QEMU (136691): E: EIP: 0x0010c173
DEBUG   - QEMU (136691): E:      0x0010c0a1 (0x7d000000)
DEBUG   - QEMU (136691): E:      0x0010335f (0x3827c5ac)
DEBUG   - QEMU (136691): E:      0x00105fcc (0x1043d8)
DEBUG   - QEMU (136691): E:      0x001043fa (0x10d088)
DEBUG   - QEMU (136691): E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
DEBUG   - QEMU (136691): E: Current thread: 0x124ac0 (test_jitter_drift_timer_period)
DEBUG   - QEMU (136691): E: Halting system
DEBUG   - QEMU (136691) complete (unexpected eof) after 0.5647683143615723 seconds

Additional context
Bisecting found this commit f0daf90 to be the culprit

[golowanow]

FPU exception at this point in the test:

zephyr/tests/kernel/timer/timer_behavior/src/jitter_drift.c

Line 212 in 4974bc0

double stddev_us = sqrtf(variance_us);

[nashif]

CONFIG_FPU needed now?

[golowanow]

CONFIG_FPU needed now?

it works for qemu_x86 and to fix this particular test, at least.

I wonder might it be a general problem with picolibc now as default libc and where config options have not been set explicitly like in this test case.

[ceolin]

CONFIG_FPU needed now?

it works for qemu_x86 and to fix this particular test, at least.

I wonder might it be a general problem with picolibc now as default libc and where config options have not been set explicitly like in this test case.

This test used to work with soft floating point ... Wondering if that is no longer supported

[keith-packard]

This test used to work with soft floating point ... Wondering if that is no longer supported

It sounds like the soft float bits aren't getting used in this case, which sounds like a toolchain configuration issue, or perhaps a problem with multilib aliasing for x86?

[keith-packard]

Nope, just an old version of picolibc that didn't handle x86 soft float (because who even does that in 2023?). It's all fixed in the current bits which are part of pr #62882 and the related SDK pr zephyrproject-rtos/sdk-ng#707 (which has already been merged).

[nashif]

Nope, just an old version of picolibc that didn't handle x86 soft float (because who even does that in 2023?). It's all fixed in the current bits which are part of pr #62882 and the related SDK pr zephyrproject-rtos/sdk-ng#707 (which has already been merged).

I thought we were testing sqrtf and friends in tests/lib/c_lib/ and it is passing with the current toolchain... Are doing something different there?

[golowanow]

I thought we were testing sqrtf and friends in tests/lib/c_lib/ and it is passing with the current toolchain... Are doing something different there?

sqrt() test is just skipped without CONFIG_FPU

zephyr/tests/lib/c_lib/src/test_sqrt.c

Lines 178 to 183 in 88b05b3

	/*
	* sqrt is not supported without FPU except on native POSIX.
	*/
	if (!(IS_ENABLED(CONFIG_FPU)
	|| IS_ENABLED(CONFIG_BOARD_NATIVE_POSIX))) {
	ztest_test_skip();

and without the above skip condition tests/lib/c_lib just fails the same way on qemu_x86 with FPU exception:

DEBUG   - QEMU (28264): START - test_sqrtf
DEBUG   - QEMU (28264): E: Floating point unit device not available
DEBUG   - QEMU (28264): E: EAX: 0x03aea380, EBX: 0x014f8b58, ECX: 0x00000000, EDX: 0x01d751c0
DEBUG   - QEMU (28264): E: ESI: 0x029f16b1, EDI: 0x029f16b0, EBP: 0x00145f0c, ESP: 0x00145efc
DEBUG   - QEMU (28264): E: EFLAGS: 0x00000206 CS: 0x0008 CR3: 0x00151000
DEBUG   - QEMU (28264): E: call trace:
DEBUG   - QEMU (28264): E: EIP: 0x00112e1a
DEBUG   - QEMU (28264): E:      0x00112d12 (0x7f800000)
DEBUG   - QEMU (28264): E:      0x0010400d (0x2edbe6ff)
DEBUG   - QEMU (28264): E:      0x00107fc9 (0x1130c8)
DEBUG   - QEMU (28264): E:      0x00104e0e (0x1130c8)
DEBUG   - QEMU (28264): E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
DEBUG   - QEMU (28264): E: Current thread: 0x121120 (test_sqrtf)
DEBUG   - QEMU (28264): Caught system error -- reason 0 0
DEBUG   - QEMU (28264): Fatal error was unexpected, aborting...

[keith-packard]

sqrt() test is just skipped without CONFIG_FPU

Fixed in #63443