<div dir="ltr">This thread is an attempt to consolidate and resolve all the issues that have been raised related to my patches- 1. <a href="https://lists.rtems.org/pipermail/devel/2020-July/060675.html">https://lists.rtems.org/pipermail/devel/2020-July/060675.html</a> and 2. <a href="https://lists.rtems.org/pipermail/devel/2020-July/061056.html">https://lists.rtems.org/pipermail/devel/2020-July/061056.html</a>. I intend to first resolve all the issues through this thread( and probably convert this into a blog-post ), before making any further changes.<div><br></div><div>1. Stack address name that needs to be passed to shm_open() - This was briefly discussed <a href="https://lists.rtems.org/pipermail/devel/2020-July/060536.html">here</a>, and I believe the reason we still have issues with this is because of my incorrect interpretation of what was suggested. My idea was that we need to assign a name like "/taskfs/pid" to each stack address on the creation of the thread. On looking around further, I realize we can have the stack address name the same as the thread name.</div><div><br></div><div>2. Switching out shared stacks- In my current implementation, removing protected stacks is done through <a href="https://github.com/ur10/rtems/blob/stack-sharing/cpukit/score/cpu/arm/cpu_asm.S#L69">assembly code</a> but the '_Stackprotection_Context_switch' which switches out the shared stack is difficult to implement in assembly. But we need to integrate the shared stack switching in the context switching code as we don't have access to executing thread attributes anywhere else.</div><div><br></div><div>3. Integration of the 'Stackprotection_attr' structure with the thread and stack control structure - The integration is a pretty straightforward task, the difficulty lies in handling the attribute offset in the assembly code, whereas having the 'Stackprotection_attr'  just after the context control attribute in the thread control structure makes handling the offset relatively easy.</div><div><br></div></div>