Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
laboger opened this issue May 3, 2021 · 4 comments
Open

Comments

@laboger
Copy link
Contributor

@laboger laboger commented May 3, 2021

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

@cherrymui cherrymui added this to the Unplanned milestone May 3, 2021
@Helflym
Copy link
Contributor

@Helflym Helflym commented May 4, 2021

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
Copy link
Contributor

@pmur pmur commented May 4, 2021

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
Copy link
Contributor Author

@laboger laboger commented May 5, 2021

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
Copy link
Contributor

@Helflym Helflym commented May 5, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants