Linking picolibc's srand to esp32c3 causes startup fault

[lgl88911]

Describe the bug
Linking picolibc's srand to esp32c3 causes startup fault

To Reproduce
Steps to reproduce the behavior:

1. Modify hello_world sample : Call srand in the main function

int main(void)
{
	srand(3);
	printf("Hello World! %s\n", CONFIG_BOARD);
	return 0;
}

3. west build -b esp32c3_devkitm sample/hello_world
4. west flash
5. Reset run, you will find startup hang-up:

I (189) boot: Loaded app from partition at offset 0x10000
I (189) boot: Disabling RNG early entropy source...

Expected behavior
Linking picolibc's srand works fine on startup。

Impact
I can‘t use picolibc's C library properly on esp32c3

Logs and console output
Via jtag/gdb I found that the fault happens in prepare_multithreading->z_setup_new_thread->setup_thread_stack, but I can‘t confirm the exact reason:

arch_system_halt (reason=reason@entry=0) at /home/frank/work/zpro/zephyr_zgp/zephyr/kernel/fatal.c:30
30 for (;;) {
(gdb) bt
#0 arch_system_halt (reason=reason@entry=0) at /home/frank/work/zpro/zephyr_zgp/zephyr/kernel/fatal.c:30
#1 0x403805cc in k_sys_fatal_error_handler (reason=reason@entry=0, esf=) at /home/frank/work/zpro/zephyr_zgp/zephyr/kernel/fatal.c:44
#2 0x403805e6 in z_fatal_error (reason=reason@entry=0, esf=) at /home/frank/work/zpro/zephyr_zgp/zephyr/kernel/fatal.c:118
#3 0x403804ca in z_riscv_fatal_error (esf=, reason=0) at /home/frank/work/zpro/zephyr_zgp/zephyr/arch/riscv/core/fatal.c:59
#4 _Fault (esf=) at /home/frank/work/zpro/zephyr_zgp/zephyr/arch/riscv/core/fatal.c:184
#5 0x403801ec in z_riscv_thread_start () at /home/frank/work/zpro/zephyr_zgp/zephyr/arch/riscv/core/isr.S:624
Backtrace stopped: frame did not save the PC

Additional context
But from the phenomenon, it seems that only linking picolibc's srand causes this phenomenon, if I switch to use newlibc it will work fine. I suspect it is related to -T${CMAKE_CURRENT_SOURCE_DIR}/../../components/esp_rom/esp32c3/ld/esp32c3.rom.newlib.ld in modules/hal/espressif/zephyr/esp32c3/CMakeLists.txt, but no further ideas.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[lgl88911]

This problem remains unresolved. Could someone provide assistance?

[sylvioalves]

Hum I thought it was solved already. Let me re-check tomorrow.

[keith-packard]

Hrm. srand is a wrapper for srandom which stores to a thread local variable, _rand_next. I bet there's some thread local storage issue at play here.

[keith-packard]

If this is a TLS specific issue, then building using newlib with TLS enabled should also fail (as that causes the kernel to use TLS for some internal operations). If this is specific to initialized TLS variables, then this should fail even with newlib:

/*
 * Copyright (c) 2012-2014 Wind River Systems, Inc.
 *
 * SPDX-License-Identifier: Apache-2.0
 */

#include <stdio.h>

__thread int tls_data_variable = 14;

int main(void)
{
	printf("Hello World! %s %d\n", CONFIG_BOARD_TARGET, tls_data_variable);

	return 0;
}

[sylvioalves]

Ok, got it. Reason it fails is because __tdata_start is placed in wrong region:
0x00000000000091e8 PROVIDE (__tdata_start = LOADADDR (tdata)), where it should be something like
0x000000003c0007bc PROVIDE (__tdata_start = ADDR (tdata)).

Seems esp32c3 linker file needs to be updated, which can be confirmed using the patch below, which makes it work by fixing the above mentioned address:

diff --git a/include/zephyr/linker/thread-local-storage.ld b/include/zephyr/linker/thread-local-storage.ld
index 5a1313e1c8c..8444d1f082e 100644
--- a/include/zephyr/linker/thread-local-storage.ld
+++ b/include/zephyr/linker/thread-local-storage.ld
@@ -20,7 +20,7 @@
         */
 #ifdef CONFIG_XIP
        /* The "master copy" of tdata should be only in flash on XIP systems */
-       PROVIDE(__tdata_start = LOADADDR(tdata));
+       PROVIDE(__tdata_start = ADDR(tdata));
 #else
        PROVIDE(__tdata_start = ADDR(tdata));
 #endif

@keith-packard Not sure if the PR linked to this issue is the final solution yet. PTAL if you can. I need to check whether we have more cases like this and/or evaluate if this is the correct fix.

[keith-packard]

I commented in the PR -- I don't think this is right.