Is __thread type modifier supported by ESP-IDF's toolchain?

[vvb333007]

Hello everyone!

I know FreeRTOS supports TLS. However it is not clear if I can use "__thread" type modifier to make my global variables to be thread-specific? Or should I use API provided by FreeRTOS and manage my global variables myself?

What I am trying to do: I am converting some application to ESP-IDF. Application uses global variables, so I want to make these variables to be "per thread" variables

Thank you!

[vvb333007]

Oh, I should be making a test by myself, before asking.

Anyway.

Yes, __thread type specifier works as it should.

PS:
No, started to celebrate too early.

When I added third variable with __thread (other two was pointer and unsigned int) the ESP32 goes into infinite reboot with StoreProhibited exception. The problems is that I don't even use this variable.

It is defined as

Code: Select all

static __thread const char *prompt = "prompt";

The exception decoded to absolute nonsence:

Code: Select all

Decoding stack results
0x4200e20b: HardwareSerial::_uartEventTask(void*) at C:\Users\WINDOWS\AppData\Local\Arduino15\packages\esp32\hardware\esp32\3.3.0\cores\esp32\HardwareSerial.cpp:268
0x42018dce: spi_flash_hal_init at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/hal\spi_flash_hal.c:143
0x40376556: call_start_cpu0 at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/xtensa/include\xt_utils.h:41

It is nonsence, because my application does not use class HardwareSerial, it is a pure C code which uses printf()

As soon as I remove __thread specifier, or variable definition completely - it works.

Any ideas?

__thread is buggy?

@ESP_igrr , @Sprite

[vvb333007]

Oh ok, I investigated the issue and found something interesting:

If you have __thread (_Thread_local) variable, which you try to assign (or read) in a function with "constructor" attribute
whole thing will crash:

Code: Select all

static __thread void *sample;

void __attribute__((constructor)) __init_sample() {
  sample = NULL;
}

My guess that it happens because .ctor section is processed before any task is created. Is this specific to xtensa toolchain or it is normal behaviour?