This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Print vector registers in natural format, not hex


[Klee, your mailer is officially weird.]

 > The current GDB behavior for 'info reg' is the following:
 > 
 > Print all floating types in natural form, followed by "(raw 0xffffffff)". 
 > Print all other types in hex; for non-vector types, additionally print the
 > register in natural format.  Unfortunately, this behavior tends to maul
 > floating point variables (they get truncated to int, and then converted to
 > hex), as well as make character data in vector variables unpleasant to read.
 > 
 > The attached patch changes the algorithm so that all vector and float
 > registers are printed in natural format, followed by "(raw 0xffffffff)".  I've
 > attached samples of the output before and after the patch; the behavior of GDB
 > should be unchanged except for vector variables.  There's no effect on the
 > results from running the testsuite on powerpc-apple-darwin or
 > i386-unknown-gnu-linux; it does require a testsuite change to altivec-regs.exp
 > on powerpc-unknown-gnu-linux.
 > 
 > (Really, I'd argue that all registers except integers should be printed as
 > natural followed by "(raw 0xffffffff)", rather than checking explicitly for
 > float/vector.  But perhaps there are types I haven't thought of, so I left
 > that part of the behavior unchanged.)
 > 
 > Before:
 > 
 > (gdb) show architecture
 > The target architecture is set automatically (currently powerpc:common)
 > (gdb) info r1 f1 v1
 > r1             0xbffff6e0       3221223136
 > f1             0        (raw 0x0000000000000000)
 > v1             {
 > uint128 = 0x606162636465666740490fdb402df854, 
 > v4_float = {0xffffffff, 0xffffffff, 0x3, 0x2}, 
 > v4_int32 = {0x60616263, 0x64656667, 0x40490fdb, 0x402df854}, 
 > v8_int16 = {0x6061, 0x6263, 0x6465, 0x6667, 0x4049, 0xfdb, 0x402d, 0xf854}, 
 > v16_int8 = {0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x40, 0x49, 0xf,
 > 0xdb, 0x40, 0x2d, 0xf8, 0x54}
 > }
 > 
 > (gdb) show architecture
 > The target architecture is set automatically (currently i386)
 > (gdb) info reg xmm0
 > xmm0           {
 > v4_float = {0x2, 0x3, 0x1, 0x0}, 
 > v2_double = {0x32, 0x0}, 
 > v16_int8 = {0x54, 0xf8, 0x2d, 0x40, 0xdb, 0xf, 0x49, 0x40, 0x3b, 0xaa, 0xb8,
 > 0x3f, 
 > 0x18, 0x72, 0x31, 0x3f}, 
 > v8_int16 = {0xf854, 0x402d, 0xfdb, 0x4049, 0xaa3b, 0x3fb8, 0x7218, 0x3f31}, 
 > v4_int32 = {0x402df854, 0x40490fdb, 0x3fb8aa3b, 0x3f317218}, 
 > v2_int64 = {0x40490fdb402df854, 0x3f3172183fb8aa3b}, 
 > uint128 = 0x3f3172183fb8aa3b40490fdb402df854
 > }
 > 
 > After:
 > 
 > (gdb) show architecture
 > The target architecture is set automatically (currently powerpc:common)
 > (gdb) info reg r1 f1 v1
 > r1             0xbffff6e0       3221223136
 > f1             0        (raw 0x0000000000000000)
 > v1             {
 > uint128 = 0x606162636465666740490fdb402df854, 
 > v4_float = {6.49626082e+19, 1.6926733e+22, 3.14159274, 2.71828175}, 
 > v4_int32 = {1616994915, 1684366951, 1078530011, 1076754516}, 
 > v8_int16 = {24673, 25187, 25701, 26215, 16457, 4059, 16429, -1964}, 
 > v16_int8 = "`abcdefg@I\017¢XZ@-¢XZT"
 > }       (raw 0x606162636465666740490fdb402df854)
 > 
 > (gdb) show architecture
 > The target architecture is set automatically (currently i386)
 > (gdb) info reg xmm0
 > xmm0           {
 > v4_float = {2.71828175, 3.14159274, 1.44269502, 0.693147182}, 
 > v2_double = {50.12387850041037, 0.00026619998945657018}, 
 > v16_int8 = "T¡Z-@¡Z\017I@;¡Z¡Z?\030r1?", 
 > v8_int16 = {-1964, 16429, 4059, 16457, -21957, 16312, 29208, 16177}, 
 > v4_int32 = {1076754516, 1078530011, 1069066811, 1060205080}, 
 > v2_int64 = {4632251126076274772, 4553546146722130491}, 
 > uint128 = 0x3f3172183fb8aa3b40490fdb402df854
 > }       (raw 0x3f3172183fb8aa3b40490fdb402df854)
 > 
 > The patch:
 > 
 > 2002-10-04  Klee Dienes  <kdienes@apple.com>
 > 
 > * infcmd.c (default_print_registers_info): Print vectors and
 > floats in 'natural' form, followed by the raw contents of the
 > register.  Print other types in hex, followed by their natural
 > form.
 > 
 > 2004-10-04  Klee Dienes <kdienes@apple.com>
 > 
 > * gdb.arch/altivec-regs.exp: Info reg now prints in natural, not
 > hex, format.
 > 
 > Index: infcmd.c
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/infcmd.c,v
 > retrieving revision 1.57
 > diff -u -r1.57 infcmd.c
 > --- infcmd.c    3 Oct 2002 02:34:07 -0000       1.57
 > +++ infcmd.c    4 Oct 2002 20:22:48 -0000
 > @@ -1628,9 +1628,13 @@
 > REGISTER_VIRTUAL_SIZE (i));
 > }
 > 
 > -      /* If virtual format is floating, print it that way, and in raw
 > -         hex.  */
 > -      if (TYPE_CODE (REGISTER_VIRTUAL_TYPE (i)) == TYPE_CODE_FLT)
 > +      /* For floating and vector registers, print the value in natural
 > +         format, followed by the contents of the register in hex.  For
 > +         all other registers, print the contents of the register in
 > +         hex, followed by the natural (typically integer) value. */
 > +
 > +      if ((TYPE_CODE (REGISTER_VIRTUAL_TYPE (i)) == TYPE_CODE_FLT)
 > +          || TYPE_VECTOR (REGISTER_VIRTUAL_TYPE (i)))
 > {
 > int j;
 > 
 > @@ -1654,14 +1658,10 @@
 > /* Print the register in hex.  */
 > val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0, 0,
 > file, 'x', 1, 0, Val_pretty_default);
 > -          /* If not a vector register, print it also according to its
 > -             natural format.  */
 > -         if (TYPE_VECTOR (REGISTER_VIRTUAL_TYPE (i)) == 0)
 > -           {
 > -             fprintf_filtered (file, "\t");
 > -             val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0, 0,
 > -                        file, 0, 1, 0, Val_pretty_default);
 > -           }
 > +          /* Also print it according to its natural format.  */
 > +         fprintf_filtered (file, "\t");
 > +         val_print (REGISTER_VIRTUAL_TYPE (i), virtual_buffer, 0, 0,
 > +                    file, 0, 1, 0, Val_pretty_default);
 > }
 > 
 > /* The SPARC wants to print even-numbered float regs as doubles
 > 

The above portion of the patch seems reasonable to me. 

I have a few concerns about the testsuite changes. I don't see you
checking in the output for the new "(raw: 0x123456789....)"
string. See below for more...

 > Index: altivec-regs.exp
 > ===================================================================
 > RCS file: /cvs/src/src/gdb/testsuite/gdb.arch/altivec-regs.exp,v
 > retrieving revision 1.1
 > diff -u -r1.1 altivec-regs.exp
 > --- altivec-regs.exp    14 May 2002 22:02:52 -0000      1.1
 > +++ altivec-regs.exp    4 Oct 2002 20:35:17 -0000
 > @@ -88,13 +88,19 @@
 > # b) the register read (below) also works.
 > 
 > if {$endianness == "big"} {
 > -set vector_register ".uint128 = 0x00000001000000010000000100000001, v4_float
 > = .0x0, 0x0, 0x0, 0x0., v4_int32 = .0x1, 0x1, 0x1, 0x1., v8_int16 = .0x0, 0x1,
 > 0x0, 0x1, 0x0, 0x1, 0x0, 0x1., v16_int8 = .0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
 > 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.."
 > +set hex_vector ".uint128 = 0x00000001000000010000000100000001, v4_float =
 > .0x0, 0x0, 0x0, 0x0., v4_int32 = .0x1, 0x1, 0x1, 0x1., v8_int16 = .0x0, 0x1,
 > 0x0, 0x1, 0x0, 0x1, 0x0, 0x1., v16_int8 = .0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0,
 > 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.."
 > } else {
 > -set vector_register ".uint128 = 0x00000001000000010000000100000001, v4_float
 > = .0x0, 0x0, 0x0, 0x0., v4_int32 = .0x1, 0x1, 0x1, 0x1., v8_int16 = .0x1, 0x0,
 > 0x1, 0x0, 0x1, 0x0, 0x1, 0x0., v16_int8 = .0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0,
 > 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.."
 > +set hex_vector ".uint128 = 0x00000001000000010000000100000001, v4_float =
 > .0x0, 0x0, 0x0, 0x0., v4_int32 = .0x1, 0x1, 0x1, 0x1., v8_int16 = .0x1, 0x0,
 > 0x1, 0x0, 0x1, 0x0, 0x1, 0x0., v16_int8 = .0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0,
 > 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.."
 > +}
 > +
 > +if {$endianness == "big"} {
 > +     set decimal_vector ".uint128 = 0x00000001000000010000000100000001,
 > v4_float = .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 = .1, 1, 1, 1.,
 > v8_int16 = .0, 1, 0, 1, 0, 1, 0, 1., v16_int8 =
 > ..0.0.0.001.0.0.0.001.0.0.0.001.0.0.0.001.."
 > +} else {
 > +     set decimal_vector ".uint128 = 0x00000001000000010000000100000001,
 > v4_float = .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 = .1, 1, 1, 1.,
 > v8_int16 = .1, 0, 1, 0, 1, 0, 1, 0., v16_int8 =
 > ..001.0.0.0.001.0.0.0.001.0.0.0.001.0.0.."
 > }
 > 

I would prefer if the above decimal_vector variable settings are left
near to where they are used in the testfile. I think it makes the
testfile easier to read if related things are close together.


 > for {set i 0} {$i < 32} {incr i 1} {
 > -        gdb_test "info reg vr$i" "vr$i.*$vector_register" "info reg vr$i"
 > +        gdb_test "info reg vr$i" "vr$i.*$decimal_vector" "info reg vr$i"
 > }
 > 
 > gdb_test "info reg vrsave" "vrsave.*0x1" "info reg vrsave"
 > @@ -106,14 +112,9 @@
 > # null char in a string and doesn't print it. This is not a failure, but
 > # the way gdb works.
 > 
 > -if {$endianness == "big"} {
 > -     set decimal_vector ".uint128 = 0x00000001000000010000000100000001,
 > v4_float = .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 = .1, 1, 1, 1.,
 > v8_int16 = .0, 1, 0, 1, 0, 1, 0, 1., v16_int8 =
 > ..0.0.0.001.0.0.0.001.0.0.0.001.0.0.0.001.."
 > -} else {
 > -     set decimal_vector ".uint128 = 0x00000001000000010000000100000001,
 > v4_float = .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 = .1, 1, 1, 1.,
 > v8_int16 = .1, 0, 1, 0, 1, 0, 1, 0., v16_int8 =
 > ..001.0.0.0.001.0.0.0.001.0.0.0.001.0.0.."
 > -}
 > -
 > for {set i 0} {$i < 32} {incr i 1} {
 > gdb_test "print \$vr$i" ".* = $decimal_vector" "print vr$i"
 > +        gdb_test "print /x \$vr$i" ".* = $hex_decimal_vector" "print vr$i"
                                             ^^^^^^^^^^^^^^^^^^^
					How could this work? 
 > }
 > 
 > gdb_test "print \$vrsave" ".* = 1" "print vrsave"


I actually removed the "info powerpc altivec" command from the
testfile, so we should also change "info powerpc altivec" into "info
vector". Would you mind doing that? I think the output needs no
changes, beyond whatever is needed to conform to your new format.

thanks
Elena


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]