The pthread_init function would always get included in the binary,
even when no pthread functions were used.
This happens due to us using -u linker flags to force the linker to
consider the pthread library, to ensure the weak pthread functions in
the toolchain are overridden.
By restructing the code to rely on lazy inits instead we can avoid using
a init function, and therefor save some space.
Closes https://github.com/espressif/esp-idf/issues/14213
Originally, pthread_internal_local_storage_destructor_callback was only called from pthread_exit
on the thread whose TLS is being destroyed.
In b3755b751e, pthread_internal_local_storage_destructor_callback
started being called from pthread_join and pthread_detach on a different thread (whichever one
called one of those functions).
But pthread_internal_local_storage_destructor_callback is still calling
vTaskSetThreadLocalStoragePointer and vTaskSetThreadLocalStoragePointerAndDelCallback with a NULL
xTaskToSet argument, which causes those functions to set the TLS pointer and deletion callback
for the current thread, not the thread whose TLS is being destroyed.
This commit makes pthread_internal_local_storage_destructor_callback call
vTaskSetThreadLocalStoragePointer and vTaskSetThreadLocalStoragePointerAndDelCallback
with the handle of the thread whose TLS is being destroyed.
This commit replaces the use of portNUM_PROCESSORS and configNUM_CORES
macros in all of ESP-IDF. These macros are needed to realize an SMP
scenario by fetching the number of active cores FreeRTOS is running on.
Instead, a new Kconfig option, CONFIG_FREERTOS_NUMBER_OF_CORES, has been
added as a proxy for the FreeRTOS config option, configNUMBER_OF_CORES.
This new commit is now used to realize an SMP scenario in various places
in ESP-IDF.
[Sudeep Mohanty: Added new Kconfig option CONFIG_FREERTOS_NUMBER_OF_CORES]
Signed-off-by: Sudeep Mohanty <sudeep.mohanty@espressif.com>
Unlike COMPILE_OPTIONS, COMPILE_DEFINITIONS CMake property assumes
values without the -D prefix, such as NAME or NAME=VAL.
Previously, IDF build system was passing COMPILE_DEFINITIONS build
property to CMake COMPILE_OPTIONS property, so -D prefix was not
a problem.
Now that COMPILE_DEFINITIONS CMake property is used, -D prefix has
to be removed.
(Note that this doesn't affect 'target_compile_definitions' function,
which strips -D prefix before adding the definition to the property.)
