Mitsis, Peter <Peter.Mitsis@...>
Apparently redefining '__stack' for both a thread's stack alignment and stack section placement will not work as we have many instances where those stacks are embedded within other structures.
Thus, I would like to modify the original proposal to the following:
1. Introduce a new tag (__stack_section) that will put thread stacks into the appropriate linker section. If CONFIG_INIT_STACKS is enabled, this stack section will be initialized to 0xaa's at boot time.
2. Rename the existing '__stack' tag to '__stack_align'. This is to make it clear that the tag is strictly for ensuring proper alignment, and that it does not become confused with '__stack_section'.
3. Update the thread initialization code to initialize its stack to 0xaa's only if ...
a. CONFIG_INIT_STACKS is enabled
b. AND the stack is not in the stack section (for when the stack is embedded in another structure).
Thoughts, comments, objections?
From: Mitsis, Peter [mailto:Peter.Mitsis(a)windriver.com]
Sent: September-21-16 4:21 PM
Subject: [devel] RFC: Initializing and placement of thread/fiber/task stacks
Any objections/comments to the following?
Thread stacks (as defined by the __stack attribute) should be placed into their own section. By default this section should be a part of the .noinit section so that they do not impact run time performance. However, if the Kconfig option INIT_STACKS is enabled, then the stacks should be placed into their own unique section and their stack space should be initialized at boot time to a known value (0xaa).
Although this will result in a longer boot time (when INIT_STACKS) is enabled, it means that aside from the potential boot time penalty, there is never a stack initialization run time penalty when creating a thread. This may be particularly beneficial should a thread be restarted or thread-space be reused as the stack will not be re-initialized. Note that this changes the semantics of thread stack usage to mean thread stack usage for all threads that use that stack.