On 31 October 2017 at 16:18, John Reiser <jrei...@bitwagon.com> wrote:
> On real Linux on PowerPC64, a system call trashes registers {r0, r4-r12,
> ctr};
> qemu-ppc64 preserves them. [Both preserve: r13-r31, r1 (sp), r2 (TOC), r3
> (set to
> return value), lr (link register).] Looking at the code in
> qemu/linux-user/syscall.c
> (tip commit 92c7ec5cd4d15c76218703f7bd3ca75bd46353b7), I do not see anything
> which
> "enforces the ABI", such as by setting all volatile registers to a random
> value,
> or a flag such as 0xA5A5A5...A5A5, or at least to 0. qemu-user should.
>
> This raises the question, "What *is* the ABI for system calls?".
> The documentation
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#REG
> does not state explicitly that a system call is the same as a subroutine
> call.
> Indeed it isn't, because a system call preserves the link register lr,
> but a subroutine call need not.
>
> So, how about qemu-user enforcing the ABI for system calls?
The ABI is in general "the caller can rely on register set A
being preserved across the syscall instruction; it cannot rely
on register set B being preserved" (for values of A and B that
vary across architectures). The kernel doesn't guarantee
that it is going to trash registers in set B; it merely does
not provide the guarantee that it won't trash them. Exactly
what happens for the set B regs is an implementation detail
and one which could vary from kernel version to kernel version.
qemu's linux-user mode implements the ABI; we happen to not
trash things in set B because of our implementation, but that's
OK because the ABI doesn't require us to trash them.
thanks
-- PMM
