All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Roland McGrath <roland@redhat.com>
Cc: Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
	Andi Kleen <ak@suse.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86-64: ptrace ia32 BP fix
Date: Tue, 5 Jul 2005 10:07:24 -0400	[thread overview]
Message-ID: <20050705140724.GA19552@nevyn.them.org> (raw)
In-Reply-To: <200507050931.j659VFEa028271@magilla.sf.frob.com>

On Tue, Jul 05, 2005 at 02:31:15AM -0700, Roland McGrath wrote:
> 
> When the 32-bit vDSO is used to make a system call, the %ebp register for
> the 6th syscall arg has to be loaded from the user stack (where it's pushed
> by the vDSO user code).  The native i386 kernel always does this before
> stopping for syscall tracing, so %ebp can be seen and modified via ptrace
> to access the 6th syscall argument.  The x86-64 kernel fails to do this,
> presenting the stack address to ptrace instead.  This makes the %rbp value
> seen by 64-bit ptrace of a 32-bit process, and the %ebp value seen by a
> 32-bit caller of ptrace, both differ from the native i386 behavior.
> 
> This patch fixes the problem by putting the word loaded from the user stack
> into %rbp before calling syscall_trace_enter, and reloading the 6th syscall
> argument from there afterwards (so ptrace can change it).  This makes the
> behavior match that of i386 kernels.

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.


-- 
Daniel Jacobowitz
CodeSourcery, LLC

  reply	other threads:[~2005-07-05 14:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-05  9:31 [PATCH] x86-64: ptrace ia32 BP fix Roland McGrath
2005-07-05 14:07 ` Daniel Jacobowitz [this message]
2005-07-05 14:16   ` Andi Kleen
2005-07-05 19:11   ` Roland McGrath
     [not found] <20050705095916.GV21330@wotan.suse.de>
2005-07-05 10:19 ` Roland McGrath

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050705140724.GA19552@nevyn.them.org \
    --to=drow@false.org \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.