Hello, About a year ago we discussed various possibilities regarding an issue with the aarch64 selection of r18 as the static chain, problematic in environments where the OS uses r18 for "private" reasons. VxWorks uses this permission to use r18 as a pointer to the current TCB, and Windows does something similar I think.
I first proposed a change allowing target ports to state that r18 should be considered "fixed" and switching the static chain to r11 in this case. I had picked r11 as the next after r9/r10 already used for stack checking, After a few exchanges, we agreed that we should rather use r9 as the alternate static chain and remap the temporary registers used for stack-checking to r10/r11. https://gcc.gnu.org/ml/gcc-patches/2018-12/msg01592.html We were also thinking that we should be able to change the static chain register unconditionally. Then during the last GNU cauldron, we realized that libffi currently relies on the knowledge of which register is used for the static chain, for the support of Go closures. Unconditionally changing r18 to something else would break that support, most notably on Linux. Adjusting libffi is possible but raises a clear compatibility issue. The attached patch is a renewed proposal to let target OS ports state their private use of r18, switching the static chain to r9 and declaring r18 "fixed" in that case. In addition to adjusting PROBE_STACK reg values to r10/r11, the patch also moves the corresponding definitions together with the other special register number definitions, so we have a centralized view of the numbering choices. This solves the immediate issue for VxWorks (which I'd like to contribute) and seems like an interesting thing to have in any case, regardless of whether or not we want to more generally change the static chain someday. With this change, we have good build and testing results on both aarch64-elf and aarch64-vxworks7 for a gcc-9 based compiler, where only vxworks states TARGET_OS_USES_R18. I have also verified that I would build a native aarch64-linux mainline compiler with the change and that it still picks r18 as the static chain. Is this variant ok to commit ? Thanks in advance, Best Regards, Olivier 2019-11-07 Olivier Hainque <hain...@adacore.com> * config/aarch64/aarch64.h: Define PROBE_STACK_FIRST_REG and PROBE_STACK_SECOND_REG here, to r10/r11 respectively. (TARGET_OS_USES_R18): New macro, default value 0 that target OS configuration files may redefine. (STATIC_CHAIN_REGNUM): r9 if TARGET_OS_USES_R18, r18 otherwise. * config/aarch64/aarch64.c (PROBE_STACK_FIRST_REG, PROBE_STACK_SECOND_REG): Remove definitions. (aarch64_conditional_register_usage): Preserve r18 if the target OS uses it, and check that the static chain selection wouldn't conflict.
aarch64-r18.diff
Description: Binary data