Re: [rfa] Handle amd64-linux %orig_rax

[Daniel Jacobowitz <drow@false.org>]

Andi, have you got any opinion on this?  The problem arises when GDB
sets %orig_rax to -1 to indicate that the interrupted syscall should
not be resumed, and then sets %rip to some other address; the kernel is
still changing %rcx on the way out to userspace.  I think this sounds
like a kernel bug.

On Tue, Oct 31, 2006 at 10:17:01AM -0800, Datoda wrote:
> Here's my explanation of the cause of this problem: According to the
> AMD64 ABI, Section A.2, Item 2., the kernel destroys %rcx in a
> syscall. Meanwhile, the calling convention uses %rcx to pass in the
> fourth argument to the function being called. Therefore, the kernel
> may trash the fourth argument to an inferior call even when it's not
> restarting the interrupted system call (i.e., when %orig_rax is set
> to a negative value) because the kernel is still in the "syscall
> mode".
> 
> A repeat inferior call returns the correct value because the kernel
> has left that syscall mode when doing the first inferior call.
> 
> It appears to me that instead of telling the kernel not to restart a
> syscall by setting %orig_rax to -1, gdb should be telling the kernel
> to forget about the syscall all together when initiating an inferior
> call, and restoring the kernel's memory about the interrupted syscall
> when the inferior call finishes. I don't know how that can be
> achieved, though.

We don't need to restore it; we can just restart the syscall from
scratch.

> Alternatively, the kernel can be made to suppress trashing %rcx when
> the process is being debugged and %orig_rax is -1. But I don't know
> the ramification/implication of this change.
> 
> Or perhaps it's just a kernel bug that needs to be fixed....
> 
> Any other insight on this?

-- 
Daniel Jacobowitz
CodeSourcery