Blame SOURCES/gdb-x86_64-i386-syscall-restart.patch

01917d
http://sourceware.org/ml/gdb-patches/2009-11/msg00592.html
01917d
Subject: [patch] Fix syscall restarts for amd64->i386 biarch
01917d
01917d
Hi,
01917d
01917d
tested only on recent Linux kernels, it should apply also on vanilla ones.
01917d
There were various changes of the kernels behavior in the past.
01917d
01917d
FSF GDB HEAD state:
01917d
kernel debugger inferior state
01917d
x86_64 x86_64   x86_64   PASS
01917d
x86_64 x86_64   i386     FAIL without this patch, PASS with this patch
01917d
x86_64 i386     i386     PASS on recent kernels
01917d
                         (FAIL: kernel-2.6.31.5-127.fc12.x86_64 - Fedora 12)
01917d
                         (PASS: kernel-2.6.32-0.55.rc8.git1.fc13.x86_64)
01917d
i386   i386     i386     PASS
01917d
01917d
01917d
Currently gdb.base/interrupt.exp fails on amd64 host running under
01917d
--target_board unix/-m32 with:
01917d
	continue
01917d
	Continuing.
01917d
	Unknown error 512
01917d
01917d
<linux/errno.h>:
01917d
/*
01917d
 * These should never be seen by user programs.  To return one of ERESTART*
01917d
 * codes, signal_pending() MUST be set.  Note that ptrace can observe these
01917d
 * at syscall exit tracing, but they will never be left for the debugged user
01917d
 * process to see.
01917d
 */
01917d
#define ERESTARTSYS     512
01917d
01917d
"Unknown error 512" printed above is printed by the inferior itself, not by GDB.
01917d
01917d
It is because GDB reads it as 0xfffffffffffffe00 but writes it back as
01917d
0xfffffe00.
01917d
+      /* Sign-extend %eax as during return from a syscall it is being checked
01917d
+	 for -ERESTART* values -512 being above 0xfffffffffffffe00; tested by
01917d
+	 interrupt.exp.  */
01917d
01917d
01917d
Quote of Roland McGrath from IRC:
01917d
01917d
roland: in the user_regset model, there are 64-bit user_regset flavors and
01917d
32-bit user_regset flavors, so at the kabi level the (kernel) caller can say
01917d
what it means: calls on the 32-bit user_regset flavor will behave as if on
01917d
a 32-bit kernel/userland.  in ptrace, there is no way for x86_64 ptrace calls
01917d
to say "i think of the inferior as being 32 bits, so act accordingly" (tho ppc
01917d
and/or sparc have ptr
01917d
roland: ace requests that do that iirc)
01917d
roland: ergo 64-bit ptrace callers must either save/restore full 64-bits so
01917d
the kernel's sign-extension choices are preserved, or else grok magic ways to
01917d
expand stored 32-bit register contents to 64-bit values to stuff via 64-bit
01917d
ptrace
01917d
[...]
01917d
roland: there is a "32-bit-flavored task", but it's not really true that it
01917d
has 32-bit registers.  there is no 32-bit-only userland condition.  any task
01917d
can always ljmp to the 64-bit code segment and run 64-bit insns including
01917d
a 64-bit syscall
01917d
roland: so a 64-bit debugger should see and be able to fiddle the full
01917d
registers.  it can even change cs via ptrace to force the inferior into
01917d
running 32 or 64 bit code.
01917d
01917d
01917d
Saving whole 64bits for i386 targets on x86_64 hosts does not much match the
01917d
GDB architecture as `struct type' for these registers still should be 32bit
01917d
etc.   Therefore provided just this exception.
01917d
01917d
The problem is reproducible only if one does an inferior call during the
01917d
interruption to do full inferior save/restore from GDB regcache.
01917d
01917d
Regression tested on {x86_64,x86_64-m32,i686}-fedora12-linux-gnu.
01917d
01917d
01917d
Thanks,
01917d
Jan
01917d
01917d
01917d
gdb/
01917d
2009-11-29  Jan Kratochvil  <jan.kratochvil@redhat.com>
01917d
01917d
	* amd64-nat.c (amd64_collect_native_gregset): Do not pre-clear %eax.
01917d
	Sign extend it afterwards.
01917d
01917d
--- a/gdb/amd64-nat.c
01917d
+++ b/gdb/amd64-nat.c
01917d
@@ -131,9 +131,9 @@ amd64_collect_native_gregset (const struct regcache *regcache,
01917d
     {
01917d
       num_regs = amd64_native_gregset32_num_regs;
01917d
 
01917d
-      /* Make sure %eax, %ebx, %ecx, %edx, %esi, %edi, %ebp, %esp and
01917d
+      /* Make sure %ebx, %ecx, %edx, %esi, %edi, %ebp, %esp and
01917d
          %eip get zero-extended to 64 bits.  */
01917d
-      for (i = 0; i <= I386_EIP_REGNUM; i++)
01917d
+      for (i = I386_ECX_REGNUM; i <= I386_EIP_REGNUM; i++)
01917d
 	{
01917d
 	  if (regnum == -1 || regnum == i)
01917d
 	    memset (regs + amd64_native_gregset_reg_offset (gdbarch, i), 0, 8);
01917d
@@ -159,4 +159,20 @@ amd64_collect_native_gregset (const struct regcache *regcache,
01917d
 	    regcache_raw_collect (regcache, i, regs + offset);
01917d
 	}
01917d
     }
01917d
+
01917d
+  if (gdbarch_bfd_arch_info (gdbarch)->bits_per_word == 32)
01917d
+    {
01917d
+      /* Sign-extend %eax as during return from a syscall it is being checked
01917d
+	 for -ERESTART* values -512 being above 0xfffffffffffffe00; tested by
01917d
+	 interrupt.exp.  */
01917d
+
01917d
+      int i = I386_EAX_REGNUM;
01917d
+
01917d
+      if (regnum == -1 || regnum == i)
01917d
+	{
01917d
+	  void *ptr = regs + amd64_native_gregset_reg_offset (gdbarch, i);
01917d
+
01917d
+	  *(int64_t *) ptr = *(int32_t *) ptr;
01917d
+	}
01917d
+    }
01917d
 }
01917d