lkml.org 
[lkml]   [2005]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] x86-64: ptrace ia32 BP fix
Date
> 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/

\
 
 \ /
  Last update: 2005-07-05 21:14    [W:0.849 / U:0.544 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site