Re: [PATCH] Adjust `pc-fp.exp' for ppc64/s390x (PR 12659)

["Ulrich Weigand" <uweigand@de.ibm.com>]

Pedro Alves wrote:
> On 07/31/2012 10:25 PM, Sergio Durigan Junior wrote:
> > While regtesting 7.4 against 7.5 branch on ppc64/s390x RHEL 6.3, I
> > noticed this failure.  The patch which introduced this failure was
> > committed because of:
> > 
> >       http://sourceware.org/bugzilla/show_bug.cgi?id=12659
> > 
> > On x86*, the output of `info register pc fp' is:
> > 
> >     info register pc fp
> >     pc: 0x400520
> >     fp: 0x7fffffffc490
> >     (gdb) PASS: gdb.base/pc-fp.exp: info register pc fp
> > 
> > On ppc64/s390x, it is:
> > 
> >     info register pc fp
> >     pc             0x10000658       0x10000658 <main+20>
> >     fp: 0xfffffffd120
> >     (gdb) FAIL: gdb.base/pc-fp.exp: info register pc fp
> > 
> > Since this difference in the output does not seem to be an error itself,
> > the patch below just adjusts the testcase to match this kind of output
> > as well.  It does not fail on x86*.
> 
> Why is the output format different?  It looks like consistency here would be good.

The problem is that "pc", "fp", etc can refer to different things under
the covers: either a register defined by the target code, or else a
"user register" defined by GDB common code.

On many targets (but not Intel), "pc" is the name of a register defined
by the target.  In this case, registers_info uses the standard
gdbarch_print_registers_info routine to output its content; this gives
a larger space between register name and value, and outputs the
contents both in hex and in the register's default type, usually a
function pointer type.

On targets where "pc" is *not* the name of a register defined by the
target, registers_info still recognizes the name as "user register",
and uses a separate code path to print its value.  This results in
a different (shorter) output ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com