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

syscall: linux-ppc64x (incorrectly?) treats R4 as a syscall return value #51192

Closed
prattmic opened this issue Feb 14, 2022 · 4 comments
Closed
Labels
arch-ppc64x FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@prattmic
Copy link
Member

All of the linux-ppc64x Syscall functions return the contents of R4 as syscall return r2.

#42178 previously ran into issues because system calls were getting inconsistent r2 values. The short-term workaround there was to ignore r2 for AllThreadsSyscall, with the assumption that some syscalls may use r2.

On further investigation, it looks like that is not true.

The Linux ppc64 system call ABI documentation lists only R3 as a return value, with R4 getting clobbered.

The system call entrypoint I find a bit difficult to follow, as it is unclear exactly what function pointers are loaded by __LOAD_HANDLER, but not seeing lots of assembly implementations, I assume these are the C system call implementations.

syscall_exit_prepare seems pretty clear that it only expects to use R3 for the return value.

Thus my conclusion is that R4 is never a syscall return value and our syscall implementations should change to unconditionally returning 0 for r2.

Anyone know if I missed something that should keep R4 in use?

cc @minux @cherrymui @aclements @AndrewGMorgan @laboger

@prattmic prattmic added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. arch-ppc64x labels Feb 14, 2022
@prattmic prattmic added this to the Go1.19 milestone Feb 14, 2022
@cherrymui
Copy link
Member

I agree what you said. I don't know why R4 was used. I think we should remove it.

@laboger
Copy link
Contributor

laboger commented Feb 14, 2022

cc @pmur

@pmur
Copy link
Contributor

pmur commented Feb 14, 2022

R4 is clobbered upon return from a syscall. Only R3 and CR0SO convey status on PPC64 via SYSCALL. Storing a consistent value of 0 to r2 seems much more reasonable than what is done now.

@gopherbot
Copy link

Change https://go.dev/cl/385796 mentions this issue: syscall: always return 0 in r2 on ppc64{,le} linux syscalls

@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 7, 2022
@golang golang locked and limited conversation to collaborators Mar 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-ppc64x FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

6 participants