This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfa] Handle amd64-linux %orig_rax
- From: Daniel Jacobowitz <drow at false dot org>
- To: Datoda <datoda at yahoo dot com>, Andi Kleen <ak at suse dot de>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 31 Oct 2006 13:22:09 -0500
- Subject: Re: [rfa] Handle amd64-linux %orig_rax
- References: <20061031181702.73135.qmail@web53714.mail.yahoo.com>
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