Hi, I'm running off of pretty close to master on GitHub, and I'm hitting this assertion: https://github.com/ChibiOS/ChibiOS/blob ... ads.c#L392 (I'm not doing anything unusual, it's a normal statically allocated thread I'm trying to start). STM32F0, so armv6m.
stktop gets aligned on PORT_NATURAL_ALIGN (4), but then we check that it's aligned to PORT_STACK_ALIGN (8). Is that intentional? Shouldn't it get aligned on PORT_STACK_ALIGN instead?
If I skip the assertion (or change the math for stktop to use PORT_STACK_ALIGN), the firmware works fine, as it did on older ChibiOS.
Thread stack alignment assertion Topic is solved
-
Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Thread stack alignment assertion
Hi,
You are right, this is a recent incomplete change on my side, now the thread structure is supposed to be always stack-aligned.
Fixed on subversion.
This has been caused by the recent introduction of the new threading API, chThdSpawnXXX() vs chThdCreateXXX(), which triggered some changes also in the old API.
The RT in trunk is being optimized for multi-core systems.The new API is like the old one except the thread_t structure is no more included in the working area but passed from outside.
Stack and thread structure being in the same RAM is no more optimal when you consider NUMA SMP systems. The stack can and should be in a core-private RAM (a TCM for example) and can be non-coherently cached, the thread structure must be in a RAM reachable by all cores and not cached (or coherently cached).
Giovanni
You are right, this is a recent incomplete change on my side, now the thread structure is supposed to be always stack-aligned.
Code: Select all
#define THD_WORKING_AREA_SIZE(n) \
(MEM_ALIGN_NEXT(PORT_WA_SIZE(n), PORT_STACK_ALIGN) + \
MEM_ALIGN_NEXT(sizeof (thread_t), PORT_STACK_ALIGN))
Fixed on subversion.
This has been caused by the recent introduction of the new threading API, chThdSpawnXXX() vs chThdCreateXXX(), which triggered some changes also in the old API.
The RT in trunk is being optimized for multi-core systems.The new API is like the old one except the thread_t structure is no more included in the working area but passed from outside.
Stack and thread structure being in the same RAM is no more optimal when you consider NUMA SMP systems. The stack can and should be in a core-private RAM (a TCM for example) and can be non-coherently cached, the thread structure must be in a RAM reachable by all cores and not cached (or coherently cached).
Giovanni