When investigating a set of GCC testsuite failures on 64-bit Solaris 10/11

	PR target/51753
	Many gcc.dg/simultate-thread tests fail on Solaris 10+/x86
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51753

it turned out that they were cause by a gdb bug.  The test boils down to
single-stepping the program under test under gdb, calling a function
before and after every single step:

	gcc/testsuite/gcc.dg/simulate-thread/simulate-thread.gdb

When I compared the execution trace between Solaris/x64 and
Linux/x86_64, I found that the Solaris gdb behaved completely
nonsensical: e.g. in this code snippet

  ret = __atomic_exchange_n (&value, max, __ATOMIC_SEQ_CST);
  if (ret != zero || value != max)
    test_abort();

both conditions were false, still test_abort was entered, but left again
without doing anything.  When I looked at %eflags in gdb, I found that
it was always shown as 0/empty, which makes no sense.  Digging around in
gdb, I found the culprit: in both amd64-sol2-tdep.c
(amd64_sol2_gregset_reg_offset) and i386-sol2-nat.c
(amd64_sol2_gregset64_reg_offs, amd64_sol2_gregset32_reg_offs) the
offset for %eflags was wrong: <sys/regset.h> has 

#define	EFL		16

for the 32-bit case, but

#define	REG_RFL		19

for 64-bit, while 16 in 64-bit is

#define	REG_ERR		16

This explains what I was seeing: when printing $eflags, I was actually
seeing the %err value (always 0, it seems), and when restoring registers
after a call, %eflags was effectively cleared, explaining the
nonsensical control flow I was seeing.

The following patch fixes this and fixes all but one of the
gcc.dg/simulate-thread tests.  I still have to investigate that last
one.

Ok for mainline?

	Rainer


2012-02-07  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* amd64-sol2-tdep.c (amd64_sol2_gregset_reg_offset): Correct
	%eflags offset.
	* i386-sol2-nat.c (amd64_sol2_gregset64_reg_offs)
	(amd64_sol2_gregset32_reg_offs): Likewise.