Re: [PATCH] x86-64 singlestep through sigreturn system call

[Roland McGrath]

> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/