Messages in this thread | | | From | Roland McGrath <> | Subject | Re: [PATCH] x86-64: ptrace ia32 BP fix | Date | Tue, 5 Jul 2005 12:11:01 -0700 (PDT) |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |