...
GLIBC support is the most straightforward, however different from previous architecture approach current one requires to add a new symbol when TCB structure is extended. This allows the compiler to bind TCB fields usage with a versioned symbol from libc, thus preventing the programs which required a new TCB field to run on older glibc version (which may lead to memory corruptions).
...
- Add the __private_ss field on struct tcbhead_t at sysdeps/powerpc/nptl/tls.h
- Add a new version and symbol at sysdeps/aarch64/Versions
- Add tests (if required)
Another option could just set the __private_ss fields support on a specific glibc support (as previously done by other architectures), however it might generate some question from community (as current TCB extension did). For this case only 1. would be required.The GCC split-stack wiki presents 6 different strategies for hold the per-thread data required by split-stack support:
- Reserve a register;
- Use a TLS variable;
- Have the stack always end at a N-bit boundary;
- Introduce a new function call which handles the comparison of the stack pointer and the stack expansion.
- Reuse the stack protector support field
- Arrange to allocate a new field in the TCB header
Each one have it downsides and pros and for current implemented split-stack support the TCB field was selected (x86, powerpc, and s390). For AArch64 the most efficient way would be also through a new field on TCB exporting a TLS variable on glibc (even with initial-exec access model) will incur in a GOT creation and access.
GCC
GCC work will require some codegen support on function prologue and epilogue. Based on powerpc split-stack patch submission:
...