Re: [PATCH] x86-64: ptrace ia32 BP fix

[Roland McGrath]

> Wouldn't this  to botch a debugger which supported both backtracing and
> PTRACE_SYSCALL, when stopped in a syscall?  We have unwind information
> for the VDSO and it's not going to tell us that the kernel has done
> something clever to the value of %ebp.

The user vDSO code pushes %ebp on the stack and then clobbers it.  The
unwind information says that %ebp was clobbered and says where the original
value can be found on the stack.  Unwinding doesn't care whether the %ebp
value is the one clobbered by the vDSO code, or the one clobbered by the
kernel (back to the previous value).  Like I said before, this matches the
i386 behavior.  If this were a problem, then it would have broken unwinding
on i386 already, but it's not a problem.

> The kernel is indeed not supposed to modify any input
> registers of syscalls (ok except rcx, but that is unavoidable)

The kernel plus the vDSO code together yield no modification.  That's the
point.  The kernel modifies %ebp in the sysenter/syscall path to match what
it would have contained if the user had done int $0x80 instead of call
vDSO.  This is the most sensible thing.  Otherwise using the unwind
information to back out of the vDSO special-frame would be required by every
tracer that wants to know the 6th argument to a system call.  (Or else it
would have to recognize the vDSO entry magically and have hard-wired
knowledge of what that does with the stack and registers.)

This change really does what I said: it makes the behavior consistent with
the i386 behavior.  Even if that were wrong (which it's not really), the
principle remains that the x86-64 support for 32-bit processes should
behave like the real 32-bit kernel does.


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/