All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hui Zhu <hui_zhu@mentor.com>
To: Hui Zhu <teawater@gmail.com>, Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: "H. Peter Anvin" <hpa@zytor.com>, <pinskia@gmail.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, <x86@kernel.org>,
	<eparis@redhat.com>, <ak@linux.intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"gdb@sourceware.org" <gdb@sourceware.org>,
	Pedro Alves <palves@redhat.com>
Subject: Re: [PATCH] Fix get ERESTARTSYS with m32 in x86_64 when debug by GDB
Date: Thu, 1 May 2014 00:35:19 +0800	[thread overview]
Message-ID: <53612647.1040604@mentor.com> (raw)
In-Reply-To: <CANFwon1OnRmXChO_uYa=ftJc8NqmvV7CRdM6hrWeyqXYUt417Q@mail.gmail.com>

On 05/01/14 00:28, Hui Zhu wrote:
> On Wed, Apr 30, 2014 at 9:35  PM, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
 >>> Date: Tue, 29 Apr 2014 22:10:15 -0700
 >>> From: "H. Peter Anvin" <hpa@zytor.com>
 >>>
 >>> On 04/29/2014 10:08 PM, Andrew Pinski wrote:
 >>>>
 >>>> restoring the values is hard since even the ptrace interface does not
 >>>> allow for that.
 >>>>
 >>>
 >>> So that begs the ultimate question, which is: given the fact that there
 >>> is *state missing* from the state vector (this is the core of the
 >>> problem), is there a way we can add that state so that gdb will be able
 >>> to save and restore it?
 >>
 >> Carrying around additional state in GDB is complicated; I'd rather
 >> avoid it.
 >>
 >> arch/x86/kernel/ptrace.c:putreg32() has this bit of code:
 >>
 >>         case offsetof(struct user32, regs.orig_eax):
 >>                 /*
 >>                  * A 32-bit debugger setting orig_eax means to restore
 >>                  * the state of the task restarting a 32-bit syscall.
 >>                  * Make sure we interpret the -ERESTART* codes correctly
 >>                  * in case the task is not actually still sitting at the
 >>                  * exit from a 32-bit syscall with TS_COMPAT still set.
 >>                  */
 >>                 regs->orig_ax = value;
 >>                 if (syscall_get_nr(child, regs) >= 0)
 >> task_thread_info(child)->status |= TS_COMPAT;
 >>                 break;
 >>
 >> which gets used for 32-bit compat ptrace(2).  Perhaps the same logic
 >> should be added to putreg() if the child is a 32-bit process?
 >
 > Make a new patch that add following code to putreg():
 > case offsetof(struct user_regs_struct, orig_ax):
 > /*
 > * A 64-bit debugger setting orig_ax of a 32-bit inferior
 > * means to restore the state of the task restarting a
 > * 32-bit syscall.
 > * Make sure we interpret the -ERESTART* codes correctly
 > * in case the task is not actually still sitting at the
 > * exit from a 32-bit syscall with TS_COMPAT still set.
 > */
 > if (test_ti_thread_flag(task_thread_info(child), TIF_IA32)) {
 > struct pt_regs *regs = task_pt_regs(child);
 > regs->orig_ax = value;
 > if (syscall_get_nr(child, regs) >= 0)
 > task_thread_info(child)->status |= TS_COMPAT;
 > return 0;
 > }
 >
 >>
 >> If (and only if) the goal of that TS_COMPAT flag solely is to trigger
 >> the error code sign-extension in 
arch/x86/asm/syscall.h:syscall_get_error(),
 >> we could work around to problem in GDB by checking "orig_ax" to see if
 >> we're continuing an interrupted system call and sign extend the error
 >> code in the real "eax" register if we are.
 >
 > I will update patch in
 > https://sourceware.org/ml/gdb-patches/2014-04/msg00429.html
 > according to this comments.
 >
 > Thanks,
 > Hui
 >

I sorry that previous patch has some format issue, post a new one.

Signed-off-by: Hui Zhu <hui@codesourcery.com>
---
--- a/arch/x86/kernel/ptrace.c
+++ b/arch/x86/kernel/ptrace.c
@@ -452,6 +452,23 @@ static int putreg(struct task_struct *ch
          if (child->thread.gs != value)
              return do_arch_prctl(child, ARCH_SET_GS, value);
          return 0;
+    case offsetof(struct user_regs_struct, orig_ax):
+        /*
+         * A 64-bit debugger setting orig_ax of a 32-bit inferior
+         * means to restore the state of the task restarting a
+         * 32-bit syscall.
+         * Make sure we interpret the -ERESTART* codes correctly
+         * in case the task is not actually still sitting at the
+         * exit from a 32-bit syscall with TS_COMPAT still set.
+         */
+        if (test_ti_thread_flag(task_thread_info(child), TIF_IA32)) {
+            struct pt_regs *regs = task_pt_regs(child);
+            regs->orig_ax = value;
+            if (syscall_get_nr(child, regs) >= 0)
+                task_thread_info(child)->status |= TS_COMPAT;
+            return 0;
+        }
+        break;
  #endif
      }



  reply	other threads:[~2014-04-30 16:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-21 16:19 [PATCH] Fix get ERESTARTSYS with m32 in x86_64 when debug by GDB Hui Zhu
2014-04-21 16:33 ` H. Peter Anvin
2014-04-30  3:44   ` Hui Zhu
2014-04-30  4:50     ` H. Peter Anvin
2014-04-30  5:08       ` Andrew Pinski
2014-04-30  5:10         ` H. Peter Anvin
2014-04-30 13:35           ` Mark Kettenis
2014-04-30 16:28             ` Hui Zhu
2014-04-30 16:35               ` Hui Zhu [this message]
2014-04-30 20:43                 ` H. Peter Anvin
2014-04-30 16:35             ` H. Peter Anvin
2014-04-30 17:49             ` Pedro Alves
2014-04-30 20:44             ` H. Peter Anvin

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=53612647.1040604@mentor.com \
    --to=hui_zhu@mentor.com \
    --cc=ak@linux.intel.com \
    --cc=eparis@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.kettenis@xs4all.nl \
    --cc=mingo@redhat.com \
    --cc=palves@redhat.com \
    --cc=pinskia@gmail.com \
    --cc=teawater@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.