Messages in this thread | | | Date | Wed, 14 Jul 2004 17:56:26 -0700 | From | Roland McGrath <> | Subject | Re: [PATCH] x86-64 singlestep through sigreturn system call |
| |
> > This patch fixes the problem by forcing a fake single-step trap at the end > > of rt_sigreturn when PTRACE_SINGLESTEP was used to enter the system call. > > I don't like this very much, see previous mail.
The previous mail addressed the subject of changing the behavior of i386 processes, where single-stepping any system call misses a trap. The native x86-64 behavior is different, and so this issue is really separate from that one. By the way, I would love it if you could explain to me with references to the x86-64 chip documentation why restoring TF with sysret seems to trap before executing the next user instruction in 64-bit mode, while restoring TF with sysexit to 32-bit user mode behaves like native 32-bit mode (as documented) and executes one instruction before taking the single-step trap.
Anyway, on native x86-64 single-stepping into `syscall' already works like a user would expect, and takes a single-step trap immediately on return from the system call before executing the first user instruction. Only stepping into an `rt_sigreturn' call behaves otherwise.
> If you really wanted to do it: > > Wouldn't it be simpler to just copy the TF bit from the previous Eflags? > This special case looks quite ugly.
I would expect that to work from the behavior I think I see with other system calls. But I've tried it and it doesn't work. Setting TF this way behaves like the i386 does: it executes one user instruction at the restored PC and then traps. I certainly find this confusing, but as I said above I still haven't explained to myself why it doesn't behave that way for normal system calls (that don't change the PC being returned to).
Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |