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

[prattmic]

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

[cherrymui]

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

[laboger]

cc @pmur

[pmur]

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]

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