Re: [RFC PATCH] x86 single-step (TF) vs system calls & traps

[Roland McGrath <roland@redhat.com>]

> They are "user-mode" only in theory.

And in every practical sense that userland ever contemplates code, except
its supplier.  When you take an asynchronous signal, your PC value might be
anywhere in the middle of the code; even when you take a synchronous signal
produced inside the system call, your PC value will be somewhere in the
middle of the code.  Hence the need for the vsyscall DSO with unwind
information.  The code does memory accesses via your stack pointer to your
normal memory, and these can fault or overflow in all the normal ways.  I
just can't see the basis for an argument that it "makes more sense" for
single-stepping these instructions to work differently than others.

Now, if single-stepping the call to the vsyscall entry point treated the
whole thing as an atomic unit and came immediately out the other side to
the return-address of that call, then we would be on the same page.  That's
actually pretty damn easy to implement with a special case for the vsyscall
PC address in do_debug.  But it would be inconsistent with the fact that
signals don't also automagically roll your PC back or forward out of the
vsyscall code section.  If we made the vsyscall entry point code truly
"virtually atomic", then I would be 100% with you on calling it "kernel code".
I somehow doubt that is what you want to do.  

That said, I don't really know why you would object to the change I've
suggested to do_debug.  It only adds code when the case of single-stepping
into sysenter actually happens.


Thanks,
Roland