cmd/compile: investigate maintaining TOC register r2 for ppc64x by default.

[laboger]

On ppc64le we have had issues over the years due to the inconsistent setting of the TOC register r2 in Go code. In the C/C++ code that is compiled to be used with cgo, r2 is initialized and expected to be valid, but with the default build mode mode for Go programs it is not.

Due to recent issues #45564 and #45850 another variation of this problem appeared again. Discussions in #45850 lead us to the topic of whether we should be maintaining r2 by default.

This can wait until Go 1.18 but wanted to be sure it didn't get forgotten. We need also need to consider linux-ppc64 (no cgo support) and aix-ppc64 (not sure how that is affected.)

@cherrymui @pmur @Helflym FYI

[Helflym]

How is the TOC not valid in linux/ppc64le ? It seems to me that on aix/ppc64 anything weird happening to the TOC would crash any programs. The TOC being the only way to access data on AIX.
However, we don't have all buildmodes available on aix/ppc64, especially plugin or shared aren't possible atm. Thus, AFAIK, R2 is always constant except when calling cgo, but the modifications are already handled.

[pmur]

The default build configuration for linux/ppc64x builds with fixed position code, so we never need to maintain it. The cgo wrappers implicitly take care of this by calling into global entry points which set up R2 when entering c code.

[laboger]

How is the TOC not valid in linux/ppc64le ? It seems to me that on aix/ppc64 anything weird happening to the TOC would crash any programs. The TOC being the only way to access data on AIX.
However, we don't have all buildmodes available on aix/ppc64, especially plugin or shared aren't possible atm. Thus, AFAIK, R2 is always constant except when calling cgo, but the modifications are already handled.

I don't know how R2 is initialized on AIX. I'd have to look at the code. If you look in runtime/rt0_aix_ppc64.s it assumes that R2 is already valid when _start is called but that is not the case for rt0_linux_ppc64le.s.

The default build configuration for linux/ppc64x builds with fixed position code, so we never need to maintain it. The cgo wrappers implicitly take care of this by calling into global entry points which set up R2 when entering c code.

Yes, if all code is built as if -buildmode=exe and no special calls are made then there is no problem. Even if you call cgo normally it should take care of R2 correctly. But once you start switching between the detault build mode and other modes and cgo there have been issues. If you look at some of the asm files in runtime for ppc64le there are some cases where R2 is saved or restored all the time even though R2 might not have been valid at the time it was saved.

There was also this issue that is somewhat related (actually related to the current Openshift problem where it was recommended to use -buildmode=pie when using plugins) is not really guaranteed to work according to this issue #43228.

[Helflym]

How is the TOC not valid in linux/ppc64le ? It seems to me that on aix/ppc64 anything weird happening to the TOC would crash any programs. The TOC being the only way to access data on AIX.
However, we don't have all buildmodes available on aix/ppc64, especially plugin or shared aren't possible atm. Thus, AFAIK, R2 is always constant except when calling cgo, but the modifications are already handled.

I don't know how R2 is initialized on AIX. I'd have to look at the code. If you look in runtime/rt0_aix_ppc64.s it assumes that R2 is already valid when _start is called but that is not the case for rt0_linux_ppc64le.s.

R2 is setup correctly by AIX loader by using the unique "TOC" symbol present in the symbol table. Thus, yes everything is done by AIX loader before rt0_aix_ppc64.s.