https://bugs.kde.org/show_bug.cgi?id=431157
--- Comment #25 from Julian Seward <jsew...@acm.org> ---
(In reply to Tom Hughes from comment #24)
> Indeed if that is -2 that would be errno 2 aka ENOENT which would make sense.
Agreed.
So then it would seem to me that the problem is that the patch doesn't
update getSyscallStatusFromGuestState. How this works is: the assembly code
in syscall-ppc64{le,be}-linux.S hands the syscall to the host, and when
it returns, it copies the result back into the guest state:
/* put the result back in the threadstate */
3: std 3,OFFSET_ppc64_GPR3(30) /* gst->GPR3 = sc result */
/* copy cr0.so back to simulated state */
mfcr 5 /* r5 = CR */
rlwinm 5,5,4,31,31 /* r5 = (CR >> 28) & 1 */
stb 5,OFFSET_ppc64_CR0_0(30) /* gst->CR0.SO = cr0.so */
So far so good. No problem there. The problem occurs slightly later, when
the main driver logic in syswrap-main.c calls getSyscallStatusFromGuestState
to find out whether the syscall failed or not, in a target-independent way.
And I am guessing this needs to be updated too. That currently computes
the result as
canonical->sres = VG_(mk_SysRes_ppc64_linux)( gst->guest_GPR3, cr0so );
meaning, it is using the legacy (R3 + CR0.S0) scheme to figure out whether
the call failed, regardless of which scheme (sc or scv) the guest originally
requested. Hence also, the syscall appears to fail or succeed depending on
what junk the kernel left for us in CR0.S0, hence the apparently random
failures that have been observed.
Fixing it would be pretty simple if getSyscallStatusFromGuestState can find
out for sure which syscall scheme was requested. That is probably safest done
by passing it sci->orig_args.
Another complication (sigh) is that this only covers the cases where we
run the syscall async:
if (sci->flags & SfMayBlock) {
/* Syscall may block, so run it asynchronously */
vki_sigset_t mask;
But this case will also need fixing
} else {
/* run the syscall directly */
and hence it looks like convert_SysRes_to_SyscallStatus will need fixing too.
--
You are receiving this mail because:
You are watching all bug changes.
