[rfa/amd64] Zero fill 32-bit registers

[rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

Hello,

For a 64-bit gregset, the code was only modifying the low 32-bits of the 
register field - leaving the upper 64-bits undefined.  This, among other 
things, would lead to mysterious 32-bit thread failures.

The attached ensures that the upper part of each fetched register is zero.

ok?
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1710 bytes --]

2004-02-25  Andrew Cagney  <cagney@redhat.com>

	* amd64-nat.c: Include "gdb_string.h".
	(amd64_collect_native_gregset): Zero fill the register.
	* Makefile.in: Update dependencies.
	
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.517
diff -u -r1.517 Makefile.in
--- Makefile.in	26 Feb 2004 23:48:01 -0000	1.517
+++ Makefile.in	27 Feb 2004 01:19:15 -0000
@@ -1536,7 +1536,7 @@
 	$(regcache_h) $(osabi_h) $(gdb_string_h) $(amd64_tdep_h) \
 	$(amd64_linux_tdep_h)
 amd64-nat.o: amd64-nat.c $(defs_h) $(gdbarch_h) $(regcache_h) \
-	$(gdb_assert_h) $(i386_tdep_h) $(amd64_tdep_h)
+	$(gdb_assert_h) $(gdb_string_h) $(i386_tdep_h) $(amd64_tdep_h)
 amd64nbsd-nat.o: amd64nbsd-nat.c $(defs_h) $(gdb_assert_h) $(amd64_tdep_h) \
 	$(amd64_nat_h)
 amd64nbsd-tdep.o: amd64nbsd-tdep.c $(defs_h) $(arch_utils_h) $(frame_h) \
Index: amd64-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-nat.c,v
retrieving revision 1.4
diff -u -r1.4 amd64-nat.c
--- amd64-nat.c	25 Feb 2004 20:59:12 -0000	1.4
+++ amd64-nat.c	27 Feb 2004 01:19:15 -0000
@@ -24,6 +24,7 @@
 #include "regcache.h"
 
 #include "gdb_assert.h"
+#include "gdb_string.h"
 
 #include "i386-tdep.h"
 #include "amd64-tdep.h"
@@ -140,7 +141,12 @@
 	  int offset = amd64_native_gregset_reg_offset (i);
 
 	  if (offset != -1)
-	    regcache_raw_collect (regcache, i, regs + offset);
+	    {
+	      regcache_raw_collect (regcache, i, regs + offset);
+	      if (register_size (gdbarch, i) < 8)
+		memset (regs + offset + register_size (gdbarch, i),
+			0, 8 - register_size (gdbarch, i));
+	    }
 	}
     }
 }

Re: [rfa/amd64] Zero fill 32-bit registers

[Mark Kettenis]

   Date: Thu, 26 Feb 2004 20:22:11 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   Hello,

   For a 64-bit gregset, the code was only modifying the low 32-bits of the 
   register field - leaving the upper 64-bits undefined.

That's not completely unintentional.  The idea is to leave any
"reserved" bits untouched, and in a sense for 32-bit stuff the upper
32 bits are "reserved"; they are not necessarily zero, at least not
for all registers.

To prevent the upper 32 bits being "undefined", typical usage of these
functions is:

      ptrace (PT_GETREGS, ..., &regs, 0);

      amd64_collect_native_gregset (current_regcache, &regs, regnum);

      ptrace (PT_SETREGS, ..., &regs, 0);

   This, among other things, would lead to mysterious 32-bit thread
   failures.

I guess the thread code isn't doing the equivalent of the PT_GETREGS
call.  I think the correct way to fix this is to make sure the buffer
is properly initialized before you pass it to
amd64_collect_native_gregset.

Another problem with your patch is that I'd rather like avoid assuming
that the register buffer is an array of 8-byte registers.

Mark

Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

>    Date: Thu, 26 Feb 2004 20:22:11 -0500
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    Hello,
> 
>    For a 64-bit gregset, the code was only modifying the low 32-bits of the 
>    register field - leaving the upper 64-bits undefined.
> 
> That's not completely unintentional.  The idea is to leave any
> "reserved" bits untouched, and in a sense for 32-bit stuff the upper
> 32 bits are "reserved"; they are not necessarily zero, at least not
> for all registers.

Er, the upper 32-bits here aren't reserved.  The request was for a 
64-bit register, and this code is erreneously only supplying half that 
value - that leaves the upper 32-bits undefined.

We've hit the same problem in the past with the MIPS.  When only 32-bits 
were available the value was expanded (in accordance with the ISA) to 
the full 64-bits.

> I guess the thread code isn't doing the equivalent of the PT_GETREGS
> call.  I think the correct way to fix this is to make sure the buffer
> is properly initialized before you pass it to
> amd64_collect_native_gregset.

Don't look at me, the buffer originated in libthread-db.

> Another problem with your patch is that I'd rather like avoid assuming
> that the register buffer is an array of 8-byte registers.

That code already assumems that, and that the values are little-endian.

Andrew

Re: [rfa/amd64] Zero fill 32-bit registers

[Mark Kettenis]

   Date: Sat, 28 Feb 2004 10:17:12 -0500
   From: Andrew Cagney <cagney@gnu.org>

   >    Date: Thu, 26 Feb 2004 20:22:11 -0500
   >    From: Andrew Cagney <ac131313@redhat.com>
   > 
   >    Hello,
   > 
   >    For a 64-bit gregset, the code was only modifying the low 32-bits of the 
   >    register field - leaving the upper 64-bits undefined.
   > 
   > That's not completely unintentional.  The idea is to leave any
   > "reserved" bits untouched, and in a sense for 32-bit stuff the upper
   > 32 bits are "reserved"; they are not necessarily zero, at least not
   > for all registers.

   Er, the upper 32-bits here aren't reserved.  The request was for a 
   64-bit register, and this code is erreneously only supplying half that 
   value - that leaves the upper 32-bits undefined.

   We've hit the same problem in the past with the MIPS.  When only 32-bits 
   were available the value was expanded (in accordance with the ISA) to 
   the full 64-bits.

I don't know enough about MIPS to be sure, but I really think AMD64 is
different; the ISA doesn't magically extend 32-bit values to 64-bit
values.

   > I guess the thread code isn't doing the equivalent of the PT_GETREGS
   > call.  I think the correct way to fix this is to make sure the buffer
   > is properly initialized before you pass it to
   > amd64_collect_native_gregset.

   Don't look at me, the buffer originated in libthread-db.

Which is in dire need of a proper maintainer.  The fact that I'm still
listed as threads maintainer doesn't mean that I've got any interest
in the crappy GNU/Linux threads implementation and the support for it
in GDB.  I'm inclined to rename thread-db.c into linux-thread-db.c and
let it rot.

That said, I really think the problem lies in libthread-db and/or
GDB's support code for libthread-db, and that it should be solved
there, not in the generic AMD64 native support code that's also used
on other platforms.

Short-term fix is probably to let fill_gregset() clear the register
buffer before calling amd64_native_collect_gregset().
store_inferior_registers() should call amd64_native_collect_gregset()
then.

   > Another problem with your patch is that I'd rather like avoid assuming
   > that the register buffer is an array of 8-byte registers.

   That code already assumems that, and that the values are little-endian.

Yes it assumes little-endianness, but the assumptions on the size of
the slots in the register buffer are weaker.  The register buffer here
corresponds to `struct reg' on the BSD's.  It would be prefectly well
possible for some of its members to be 4 bytes in size.  The current
code works for that case, whereas with your patch, it could thrash
another member of the structure.

Mark

Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

>    Date: Sat, 28 Feb 2004 10:17:12 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    >    Date: Thu, 26 Feb 2004 20:22:11 -0500
>    >    From: Andrew Cagney <ac131313@redhat.com>
>    > 
>    >    Hello,
>    > 
>    >    For a 64-bit gregset, the code was only modifying the low 32-bits of the 
>    >    register field - leaving the upper 64-bits undefined.
>    > 
>    > That's not completely unintentional.  The idea is to leave any
>    > "reserved" bits untouched, and in a sense for 32-bit stuff the upper
>    > 32 bits are "reserved"; they are not necessarily zero, at least not
>    > for all registers.
> 
>    Er, the upper 32-bits here aren't reserved.  The request was for a 
>    64-bit register, and this code is erreneously only supplying half that 
>    value - that leaves the upper 32-bits undefined.
> 
>    We've hit the same problem in the past with the MIPS.  When only 32-bits 
>    were available the value was expanded (in accordance with the ISA) to 
>    the full 64-bits.
> 
> I don't know enough about MIPS to be sure, but I really think AMD64 is
> different; the ISA doesn't magically extend 32-bit values to 64-bit
> values.

(That's why I zero extended).

The problem with MIPS is that the code, instead of always being locally 
consistent, assume that problems like this were handled elsewhere - they 
never were or were not handled consistently.  Only when MIPS started 
being locally consistent (and the mantra that addresses shall always be 
sign extended) did the code become robust, and the bugs disappear.  It 
became possible to mix 'n' match 32-bit and 64-bit code.

Here amd64 has the same problem - all 32x64-bit code needs to ensure 
that it is locally consistent.  If asked to supply a 64-bit register, 
supply the full 64-bits, and not hope something else is filling in the 
upper 32-bits.

>    > I guess the thread code isn't doing the equivalent of the PT_GETREGS
>    > call.  I think the correct way to fix this is to make sure the buffer
>    > is properly initialized before you pass it to
>    > amd64_collect_native_gregset.
> 
>    Don't look at me, the buffer originated in libthread-db.

> Short-term fix is probably to let fill_gregset() clear the register
> buffer before calling amd64_native_collect_gregset().
> store_inferior_registers() should call amd64_native_collect_gregset()
> then.

It doesn't address the underlying problem where fetching an individual 
register leaves half the register field undefined.   The code shouldn't 
assume that other code has magically initialized the rest of that 
register field.

>    > Another problem with your patch is that I'd rather like avoid assuming
>    > that the register buffer is an array of 8-byte registers.
> 
>    That code already assumems that, and that the values are little-endian.
> 
> Yes it assumes little-endianness, but the assumptions on the size of
> the slots in the register buffer are weaker.  The register buffer here
> corresponds to `struct reg' on the BSD's.  It would be prefectly well
> possible for some of its members to be 4 bytes in size.  The current
> code works for that case, whereas with your patch, it could thrash
> another member of the structure.

Do you know of any such an system?

Andrew

Re: [rfa/amd64] Zero fill 32-bit registers

[Mark Kettenis]

   Date: Sat, 28 Feb 2004 14:18:07 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > I don't know enough about MIPS to be sure, but I really think AMD64 is
   > different; the ISA doesn't magically extend 32-bit values to 64-bit
   > values.

   (That's why I zero extended).

   The problem with MIPS is that the code, instead of always being locally 
   consistent, assume that problems like this were handled elsewhere - they 
   never were or were not handled consistently.  Only when MIPS started 
   being locally consistent (and the mantra that addresses shall always be 
   sign extended) did the code become robust, and the bugs disappear.  It 
   became possible to mix 'n' match 32-bit and 64-bit code.

The problem with MIPS is that it has far too many ABI's ;-).

   Here amd64 has the same problem - all 32x64-bit code needs to ensure 
   that it is locally consistent.  If asked to supply a 64-bit register, 
   supply the full 64-bits, and not hope something else is filling in the 
   upper 32-bits.

Hmm, actually the AMD64 Architecture Programmer's Manual explicitly
says that the 16 general purpose registers are "zero-extended for
32-bit operands", so I guess zero-extending makes sense here.

It doesn't say anthing about %rip, but that makes sense since you
can't change it directly.  Zero-extending makes sense though.

I'm not sure about %eflags.  Hmm, it should probably be named %rflags.
Its upper 32-bits are reserved, and read as zero.  The manual says
that anything you write to the upper 32 bits is ignored.  I get the
feeling that we should leave the upper bits alone, just in case they
ever get used for new processors.

The segment registers are wierd anyway, since they're 16-bit
regsisters in reality.  Zero extending shouldn't be a problem here,
but these registers could pose a problem. See below.

   > Short-term fix is probably to let fill_gregset() clear the register
   > buffer before calling amd64_native_collect_gregset().
   > store_inferior_registers() should call amd64_native_collect_gregset()
   > then.

   It doesn't address the underlying problem where fetching an individual 
   register leaves half the register field undefined.   The code shouldn't 
   assume that other code has magically initialized the rest of that 
   register field.

OK, but you realize its the problem of the threads code, and *not* the
code amd64-nat.c?

   >    > Another problem with your patch is that I'd rather like avoid assuming
   >    > that the register buffer is an array of 8-byte registers.
   > 
   >    That code already assumems that, and that the values are little-endian.
   > 
   > Yes it assumes little-endianness, but the assumptions on the size of
   > the slots in the register buffer are weaker.  The register buffer here
   > corresponds to `struct reg' on the BSD's.  It would be prefectly well
   > possible for some of its members to be 4 bytes in size.  The current
   > code works for that case, whereas with your patch, it could thrash
   > another member of the structure.

   Do you know of any such an system?

Actually GNU/Linux x86-64 has a gregset_t where %cs, %fs and %gs are
stored in a short.

Could you live with just zero-extending the 16 general-purpose
registers and the instruction pointer?  I'll implement it for you.

Mark

Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

>    It doesn't address the underlying problem where fetching an individual 
>    register leaves half the register field undefined.   The code shouldn't 
>    assume that other code has magically initialized the rest of that 
>    register field.
> 
> OK, but you realize its the problem of the threads code, and *not* the
> code amd64-nat.c?

Both are broken - "society is to blame".

>    >    > Another problem with your patch is that I'd rather like avoid assuming
>    >    > that the register buffer is an array of 8-byte registers.
>    > 
>    >    That code already assumems that, and that the values are little-endian.
>    > 
>    > Yes it assumes little-endianness, but the assumptions on the size of
>    > the slots in the register buffer are weaker.  The register buffer here
>    > corresponds to `struct reg' on the BSD's.  It would be prefectly well
>    > possible for some of its members to be 4 bytes in size.  The current
>    > code works for that case, whereas with your patch, it could thrash
>    > another member of the structure.
> 
>    Do you know of any such an system?
> 
> Actually GNU/Linux x86-64 has a gregset_t where %cs, %fs and %gs are
> stored in a short.
> 
> Could you live with just zero-extending the 16 general-purpose
> registers and the instruction pointer?  I'll implement it for you.

It is certainly an improvement!  Can you test it?

Andrew

[PATCH] Re: [rfa/amd64] Zero fill 32-bit registers

[Mark Kettenis]

   Date: Sat, 28 Feb 2004 15:39:47 -0500
   From: Andrew Cagney <cagney@gnu.org>

   > Could you live with just zero-extending the 16 general-purpose
   > registers and the instruction pointer?  I'll implement it for you.

   It is certainly an improvement!  Can you test it?

I've tested the attached on SuSE 8.2, with -m32.  No changes in the
testoutput for me, but the threaded stuff doesn't work very well on
the system (and probably no at all in on 32x64-bit).  I committed it
anyway, since I can't imagine this making things worse for the
threaded stuff if it works for the non-threaded stuff.  I'd appreciate
it if you could test whether this fixed the problems you were seeing.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
 
	* amd64-nat.c: Include "gdb_string.h".
	(amd64_collect_native_gregset): Zero-extend the 32-bit
	general-purpose registers and %eip.

Index: amd64-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-nat.c,v
retrieving revision 1.4
diff -u -p -r1.4 amd64-nat.c
--- amd64-nat.c 25 Feb 2004 20:59:12 -0000 1.4
+++ amd64-nat.c 28 Feb 2004 21:54:26 -0000
@@ -24,6 +24,7 @@
 #include "regcache.h"
 
 #include "gdb_assert.h"
+#include "gdb_string.h"
 
 #include "i386-tdep.h"
 #include "amd64-tdep.h"
@@ -128,7 +129,17 @@ amd64_collect_native_gregset (const stru
   int i;
 
   if (gdbarch_ptr_bit (gdbarch) == 32)
-    num_regs = amd64_native_gregset32_num_regs;
+    {
+      num_regs = amd64_native_gregset32_num_regs;
+
+      /* Make sure %eax, %ebx, %ecx, %edx, %esi, %edi, %ebp, %esp and
+         %eip get zero-extended to 64 bits.  */
+      for (i = 0; i <= I386_EIP_REGNUM; i++)
+	{
+	  if (regnum == -1 || regnum == i)
+	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
+	}
+    }
 
   if (num_regs > NUM_REGS)
     num_regs = NUM_REGS;

Re: [PATCH] Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

>    Date: Sat, 28 Feb 2004 15:39:47 -0500
>    From: Andrew Cagney <cagney@gnu.org>
> 
>    > Could you live with just zero-extending the 16 general-purpose
>    > registers and the instruction pointer?  I'll implement it for you.
> 
>    It is certainly an improvement!  Can you test it?
> 
> I've tested the attached on SuSE 8.2, with -m32.  No changes in the
> testoutput for me, but the threaded stuff doesn't work very well on
> the system (and probably no at all in on 32x64-bit).  I committed it
> anyway, since I can't imagine this making things worse for the
> threaded stuff if it works for the non-threaded stuff.  I'd appreciate
> it if you could test whether this fixed the problems you were seeing.

The segment registers have the same problem, is the attached ok? 6.1? 
With it applied I get test results that approach i386.

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 797 bytes --]

2004-02-29  Andrew Cagney  <cagney@redhat.com>

	* amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
	32-bit segment registers.

Index: amd64-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-nat.c,v
retrieving revision 1.5
diff -u -r1.5 amd64-nat.c
--- amd64-nat.c	28 Feb 2004 21:55:48 -0000	1.5
+++ amd64-nat.c	29 Feb 2004 23:08:08 -0000
@@ -139,6 +139,12 @@
 	  if (regnum == -1 || regnum == i)
 	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
 	}
+      /* Ditto for %cs, %ss, %ds, %es, %fs, and %gs.  */
+      for (i = I386_CS_REGNUM; i < I386_ST0_REGNUM; i++)
+	{
+	  if (regnum == -1 || regnum == i)
+	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
+	}
     }
 
   if (num_regs > NUM_REGS)

Re: [PATCH] Re: [rfa/amd64] Zero fill 32-bit registers

[Mark Kettenis]

   Date: Sun, 29 Feb 2004 18:11:42 -0500
   From: Andrew Cagney <cagney@gnu.org>

   >    Date: Sat, 28 Feb 2004 15:39:47 -0500
   >    From: Andrew Cagney <cagney@gnu.org>
   > 
   >    > Could you live with just zero-extending the 16 general-purpose
   >    > registers and the instruction pointer?  I'll implement it for you.
   > 
   >    It is certainly an improvement!  Can you test it?
   > 
   > I've tested the attached on SuSE 8.2, with -m32.  No changes in the
   > testoutput for me, but the threaded stuff doesn't work very well on
   > the system (and probably no at all in on 32x64-bit).  I committed it
   > anyway, since I can't imagine this making things worse for the
   > threaded stuff if it works for the non-threaded stuff.  I'd appreciate
   > it if you could test whether this fixed the problems you were seeing.

   The segment registers have the same problem, is the attached ok? 6.1? 
   With it applied I get test results that approach i386.

   2004-02-29  Andrew Cagney  <cagney@redhat.com>

	   * amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
	   32-bit segment registers.

OK.  Feel free to add the segment registers to enum i386_regnum and
use <= I386_GS_REGNUM instead of < I386_ST0_REGNUM though.

Mark

Re: [PATCH] Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

>    The segment registers have the same problem, is the attached ok? 6.1? 
>    With it applied I get test results that approach i386.
> 
>    2004-02-29  Andrew Cagney  <cagney@redhat.com>
> 
> 	   * amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
> 	   32-bit segment registers.
> 
> OK.  Feel free to add the segment registers to enum i386_regnum and
> use <= I386_GS_REGNUM instead of < I386_ST0_REGNUM though.

Attatched is what I've committed (mainline and, in two ticks, 6.1).

A GDB, with that PC==0 hack to work around the GLIBC problems applied, 
gets these unexpected failures:

FAIL: gdb.base/gcore.exp: where in corefile (pattern 1)
FAIL: gdb.base/gcore.exp: corefile restored general registers
FAIL: gdb.base/gcore.exp: corefile restored all registers
FAIL: gdb.base/gcore.exp: capture_command_output failed on print 
array_func::local_array.
FAIL: gdb.base/gcore.exp: corefile restored stack array
FAIL: gdb.base/gcore.exp: corefile restored backtrace
FAIL: gdb.base/interrupt.exp: echo data (timeout)
FAIL: gdb.base/signals.exp: continue to func1 (probably kernel bug)
FAIL: gdb.base/signals.exp: continue to handler (the program exited)
FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads
FAIL: gdb.threads/gcore-thread.exp: a corefile thread is executing thread2
FAIL: gdb.threads/gcore-thread.exp: thread2 is current thread in corefile
                 === gdb Summary ===

# of expected passes            9860
# of unexpected failures        12
# of unexpected successes       1
# of expected failures          47
# of unknown successes          12
# of known failures             33
# of untested testcases         3
# of unsupported tests          1

not bad, eh :-)

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1587 bytes --]

2004-03-02  Andrew Cagney  <cagney@redhat.com>

	* i386-tdep.h (enum i386_regnum): Add I386_DS_REGNUM,
	I386_ES_REGNUM, I386_FS_REGNUM, and I386_GS_REGNUM.  Remove
	trailing comma and redundant assignment of I386_ST0_REGNUM.
	* amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
	32-bit segment registers.

Index: amd64-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-nat.c,v
retrieving revision 1.5
diff -u -r1.5 amd64-nat.c
--- amd64-nat.c	28 Feb 2004 21:55:48 -0000	1.5
+++ amd64-nat.c	2 Mar 2004 15:53:26 -0000
@@ -139,6 +139,12 @@
 	  if (regnum == -1 || regnum == i)
 	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
 	}
+      /* Ditto for %cs, %ss, %ds, %es, %fs, and %gs.  */
+      for (i = I386_CS_REGNUM; i <= I386_GS_REGNUM; i++)
+	{
+	  if (regnum == -1 || regnum == i)
+	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
+	}
     }
 
   if (num_regs > NUM_REGS)
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.36
diff -u -r1.36 i386-tdep.h
--- i386-tdep.h	22 Feb 2004 11:19:14 -0000	1.36
+++ i386-tdep.h	2 Mar 2004 15:53:26 -0000
@@ -166,7 +166,11 @@
   I386_EFLAGS_REGNUM,		/* %eflags */
   I386_CS_REGNUM,		/* %cs */
   I386_SS_REGNUM,		/* %ss */
-  I386_ST0_REGNUM = 16,		/* %st(0) */
+  I386_DS_REGNUM,		/* %ds */
+  I386_ES_REGNUM,		/* %es */
+  I386_FS_REGNUM,		/* %fs */
+  I386_GS_REGNUM,		/* %gs */
+  I386_ST0_REGNUM		/* %st(0) */
 };
 
 #define I386_NUM_GREGS	16

Re: [PATCH] Re: [rfa/amd64] Zero fill 32-bit registers

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]

>    The segment registers have the same problem, is the attached ok? 6.1? 
>    With it applied I get test results that approach i386.
> 
>    2004-02-29  Andrew Cagney  <cagney@redhat.com>
> 
> 	   * amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
> 	   32-bit segment registers.
> 
> OK.  Feel free to add the segment registers to enum i386_regnum and
> use <= I386_GS_REGNUM instead of < I386_ST0_REGNUM though.

Attatched is what I've committed (mainline and, in two ticks, 6.1).

A GDB, with that PC==0 hack to work around the GLIBC problems applied, 
gets these unexpected failures:

FAIL: gdb.base/gcore.exp: where in corefile (pattern 1)
FAIL: gdb.base/gcore.exp: corefile restored general registers
FAIL: gdb.base/gcore.exp: corefile restored all registers
FAIL: gdb.base/gcore.exp: capture_command_output failed on print 
array_func::local_array.
FAIL: gdb.base/gcore.exp: corefile restored stack array
FAIL: gdb.base/gcore.exp: corefile restored backtrace
FAIL: gdb.base/interrupt.exp: echo data (timeout)
FAIL: gdb.base/signals.exp: continue to func1 (probably kernel bug)
FAIL: gdb.base/signals.exp: continue to handler (the program exited)
FAIL: gdb.threads/gcore-thread.exp: corefile contains at least two threads
FAIL: gdb.threads/gcore-thread.exp: a corefile thread is executing thread2
FAIL: gdb.threads/gcore-thread.exp: thread2 is current thread in corefile
                 === gdb Summary ===

# of expected passes            9860
# of unexpected failures        12
# of unexpected successes       1
# of expected failures          47
# of unknown successes          12
# of known failures             33
# of untested testcases         3
# of unsupported tests          1

not bad, eh :-)

Andrew


[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1587 bytes --]

2004-03-02  Andrew Cagney  <cagney@redhat.com>

	* i386-tdep.h (enum i386_regnum): Add I386_DS_REGNUM,
	I386_ES_REGNUM, I386_FS_REGNUM, and I386_GS_REGNUM.  Remove
	trailing comma and redundant assignment of I386_ST0_REGNUM.
	* amd64-nat.c (amd64_collect_native_gregset): Zero-extend the
	32-bit segment registers.

Index: amd64-nat.c
===================================================================
RCS file: /cvs/src/src/gdb/amd64-nat.c,v
retrieving revision 1.5
diff -u -r1.5 amd64-nat.c
--- amd64-nat.c	28 Feb 2004 21:55:48 -0000	1.5
+++ amd64-nat.c	2 Mar 2004 15:53:26 -0000
@@ -139,6 +139,12 @@
 	  if (regnum == -1 || regnum == i)
 	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
 	}
+      /* Ditto for %cs, %ss, %ds, %es, %fs, and %gs.  */
+      for (i = I386_CS_REGNUM; i <= I386_GS_REGNUM; i++)
+	{
+	  if (regnum == -1 || regnum == i)
+	    memset (regs + amd64_native_gregset_reg_offset (i), 0, 8);
+	}
     }
 
   if (num_regs > NUM_REGS)
Index: i386-tdep.h
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.h,v
retrieving revision 1.36
diff -u -r1.36 i386-tdep.h
--- i386-tdep.h	22 Feb 2004 11:19:14 -0000	1.36
+++ i386-tdep.h	2 Mar 2004 15:53:26 -0000
@@ -166,7 +166,11 @@
   I386_EFLAGS_REGNUM,		/* %eflags */
   I386_CS_REGNUM,		/* %cs */
   I386_SS_REGNUM,		/* %ss */
-  I386_ST0_REGNUM = 16,		/* %st(0) */
+  I386_DS_REGNUM,		/* %ds */
+  I386_ES_REGNUM,		/* %es */
+  I386_FS_REGNUM,		/* %fs */
+  I386_GS_REGNUM,		/* %gs */
+  I386_ST0_REGNUM		/* %st(0) */
 };
 
 #define I386_NUM_GREGS	16