Only allow one thread for unsafe stdlib #1907
Conversation
|
@mbed-bot: TEST HOST_OSES=windows |
2 similar comments
|
@mbed-bot: TEST HOST_OSES=windows |
|
@mbed-bot: TEST HOST_OSES=windows |
|
[Build 463] |
|
@mbed-bot: TEST HOST_OSES=windows |
|
[Build 464] |
|
@mbed-bot: TEST HOST_OSES=windows |
The main stack ends at the start of the heap. In some configurations this causes the guard word to be overwritten when memory is allocated. This causes an OS error in RTX since it appears that the main stack overflowed. This patch moves the main stack to the upper 1/4th of the heap which prevents the guard word from getting overwritten.
The define OS_TCB_SIZE does not match the real stack size. This leaves the system with less than OS_TASKCNT TCBs and prevents a single thread configuration. This updates OS_TCB_SIZE to the correct value to fix the problem.
When using a standard library which does not support multi-threading allow only one thread to be used. This allows the code to remain safe.
When the malloc lock and unlock functions are inside a library they conflict with the standard libraries weak version of these functions. This is because of the way weak references are handled by the linker. This patch renames the lock and unlock functions defined inside RTX so they do not conflict. A thunk inside retarget.cpp then calls the RTX functions. This problem does not occur with retarget.cpp since it is always build into an object file rather than a library file.
|
[Build 467] |
c1728p9
force-pushed
the
only_allow_one_thread_for_unsafe_stdlib
branch
from
0bf8adf to
d0b7b3b
Compare
|
@mbed-bot: TEST HOST_OSES=windows |
| @@ -50,7 +50,7 @@ | |||
| #define _declare_box(pool,size,cnt) uint32_t pool[(((size)+3)/4)*(cnt) + 3] | |||
| #define _declare_box8(pool,size,cnt) uint64_t pool[(((size)+7)/8)*(cnt) + 2] | |||
|
|
|||
| #define OS_TCB_SIZE 52 | |||
| #define OS_TCB_SIZE 60 | |||
There was a problem hiding this comment.
is this sizeof OS_TCB as I recall? have we changed it , or the 52 was miscalculation on our side?
I dont fully understand the fix (how it fixes)
There was a problem hiding this comment.
Yep, it is the size of OS_TCB. It was defiantly too small on the cortex M. I didn't run the cortex A but I think this one was too small as well.
There was a problem hiding this comment.
I git blame, seems like void *context was aded there, did I miss anything else? that would make it only increased by 4?
There was a problem hiding this comment.
I printed out the size for cortex M and it was 60
There was a problem hiding this comment.
ah ok, so for cortex-m it's 60,but cortex a was not changed with context pointer, thus might be different.
cc @TomoYamanaka please have a look at this changeset
There was a problem hiding this comment.
Hi.
Code of review test is completed.There is no problem.
Regards,
Yamanaka
|
[Build 470] |
|
Hello @c1728p9. Something has been decided about the limit between the |
|
Hi @svastm, it doesn't hurt to change the default to ARM. The default toolchain field might be removed in the future though since this is duplicate information. |
|
I don't understand the choosen "default_build" options: e.g. an EFM32PG with 256KB/32KB (flash/ram) gets a "default_build": "standard", a lot of other MCUs several with much more flash/ram (STM32F407VG with 1024kb/192kb, ...) gets a "default_build": "small". A DISCO_F401VC gets a "default_build": "standard" and a NUCLEO_F401RE - same mcu but with twice the flash size - gets only a "default_build": "small". Why? With this option RTOS is not available (for GCC) maybe also other things did not work. |
No description provided.