[rtabi64?] Add method for Software-based TLS Pointer Retrieval

[xerpi]

This proposal requests the addition of a method for software-based TLS pointer retrieval in the AArch64 ABI. A proposed implementation, similar to the approach used in AArch32 with __aeabi_read_tp(), is outlined in llvm/llvm-project#130932.

In that implementation, an option is provided to obtain the TLS pointer via a call to a user/libc-defined __aarch64_read_tp() (enabled with the -mtp=soft flag in clang), which is necessary for platforms like Nintendo Switch Horizon OS. On such systems, the TLS pointer is determined by a calculated offset from TPIDR_EL0 rather than being directly accessible from a dedicated register.

[smithp35]

Thanks for raising the issue. I've started a discussion internally. There looks to be some precedent for using __arch64_ as a prefix for runtime functions as compiler-rt already has __aarch64_sme_accessible(void)

For now I'm planning to add to #311 which describes thread local storage.

Strictly speaking this is runtime abi (not specific to sysvabi) but we don't have a 64-bit equivalent to the rtabi32 yet. If we create one, then I expect the description to move.

[Wilco1]

What is the actual sequence to get the TLS pointer? If it's an indirection at a fixed offset from TPIDR_EL0 then that could be emitted by compilers to avoid the overhead of a call.

[kitlith]

When using devkitA64 (i.e. patched GCC including -mtp=soft for aarch64 using the above proposed scheme), libnx implements __aarch64_read_tp() here:

https://github.com/switchbrew/libnx/blob/2e2b110668633169bb97f938d219cca0cfc0831d/nx/source/runtime/readtp.s#L6-L9

Minor note, it's pulling from TPIDRRO_EL0, not TPIDR_EL0.