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 <hainque@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.