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

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

[Klee Dienes]

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

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°Z@-°ZT"
}       (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╴-@╴\017I@;╴╴?\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

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.."
  }

  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"
  }

  gdb_test "print \$vrsave" ".* = 1" "print vrsave"

[-- Attachment #2: Type: text/enriched, Size: 9617 bytes --]

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°Z@-°ZT"

}       (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<fontfamily><param>LastResort</param>╴</fontfamily>-@<fontfamily><param>LastResort</param>╴</fontfamily>\017I@;<fontfamily><param>LastResort</param>╴╴</fontfamily>?\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


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.."

 }

 

 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"

 }

 

 gdb_test "print \$vrsave" ".* = 1" "print vrsave"

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

[Daniel Jacobowitz]

Just got one nit.

On Fri, Oct 04, 2002 at 04:41:48PM -0400, Klee Dienes wrote:
> Before: 
> 
> (gdb) show architecture 
> The target architecture is set automatically (currently powerpc:common) 

>   v16_int8 = {0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x40, 
> 0x49, 0xf, 0xdb, 0x40, 0x2d, 0xf8, 0x54} 

> After: 

>   v16_int8 = "`abcdefg@I\017°Z@-°ZT" 

First of all, in characters
  v16_int8 = {'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', '@', 'I', '\017', '°', 'Z', '@', '-', '°', 'Z', 'T'}

is more natural to me.  It's a vector of chars, not a string.

Secondly, this is an 'int8' type.  Are characters really the way to go?


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Klee Dienes]

On Friday, October 4, 2002, at 04:53 PM, Daniel Jacobowitz wrote:

> Just got one nit.
>
> First of all, in characters
>   v16_int8 = {'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', '@', 'I', 
> '\017', '°', 'Z', '@', '-', '°', 'Z', 'T'}
>
> is more natural to me.  It's a vector of chars, not a string.
>
> Secondly, this is an 'int8' type.  Are characters really the way to go?

Although I agree with you, that's not really a result of this patch, 
but rather long-standing GDB behavior.  The patch is only causing $v1 
to be printed according to its type declaration, which in this case is:

type = union __gdb_builtin_type_vec128 {
     int128_t uint128;
     float v4_float[4];
     int32_t v4_int32[4];
     int16_t v8_int16[8];
     int8_t v16_int8[16];
}

Then the following code in c-valprint.c causes it to be printed as a 
string:

           /* For an array of chars, print with string syntax.  */
           if (eltlen == 1 &&
               ((TYPE_CODE (elttype) == TYPE_CODE_INT)
                || ((current_language->la_language == language_m2)
                    && (TYPE_CODE (elttype) == TYPE_CODE_CHAR)))
               && (format == 0 || format == 's'))

You could probably make a good case that arrays of 'int' should be 
printed as you describe, but that's a debate I'll leave to someone else.

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

[Daniel Jacobowitz]

On Fri, Oct 04, 2002 at 05:11:27PM -0400, Klee Dienes wrote:
> On Friday, October 4, 2002, at 04:53 PM, Daniel Jacobowitz wrote:
> 
> >Just got one nit.
> >
> >First of all, in characters
> >  v16_int8 = {'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', '@', 'I', 
> >'\017', '°', 'Z', '@', '-', '°', 'Z', 'T'}
> >
> >is more natural to me.  It's a vector of chars, not a string.
> >
> >Secondly, this is an 'int8' type.  Are characters really the way to go?
> 
> Although I agree with you, that's not really a result of this patch, 
> but rather long-standing GDB behavior.  The patch is only causing $v1 
> to be printed according to its type declaration, which in this case is:
> 
> type = union __gdb_builtin_type_vec128 {
>     int128_t uint128;
>     float v4_float[4];
>     int32_t v4_int32[4];
>     int16_t v8_int16[8];
>     int8_t v16_int8[16];
> }
> 
> Then the following code in c-valprint.c causes it to be printed as a 
> string:
> 
>           /* For an array of chars, print with string syntax.  */
>           if (eltlen == 1 &&
>               ((TYPE_CODE (elttype) == TYPE_CODE_INT)
>                || ((current_language->la_language == language_m2)
>                    && (TYPE_CODE (elttype) == TYPE_CODE_CHAR)))
>               && (format == 0 || format == 's'))
> 
> You could probably make a good case that arrays of 'int' should be 
> printed as you describe, but that's a debate I'll leave to someone else.

Ah, you're right.  Thanks for the detail.

Otherwise, I like Klee's patch... anyone else?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Elena Zannoni]

Daniel Jacobowitz writes:
 > On Fri, Oct 04, 2002 at 05:11:27PM -0400, Klee Dienes wrote:
 > > On Friday, October 4, 2002, at 04:53 PM, Daniel Jacobowitz wrote:
 > > 
 > > >Just got one nit.
 > > >
 > > >First of all, in characters
 > > >  v16_int8 = {'`', 'a', 'b', 'c', 'd', 'e', 'f', 'g', '@', 'I', 
 > > >'\017', '°', 'Z', '@', '-', '°', 'Z', 'T'}
 > > >
 > > >is more natural to me.  It's a vector of chars, not a string.
 > > >
 > > >Secondly, this is an 'int8' type.  Are characters really the way to go?
 > > 
 > > Although I agree with you, that's not really a result of this patch, 
 > > but rather long-standing GDB behavior.  The patch is only causing $v1 
 > > to be printed according to its type declaration, which in this case is:
 > > 
 > > type = union __gdb_builtin_type_vec128 {
 > >     int128_t uint128;
 > >     float v4_float[4];
 > >     int32_t v4_int32[4];
 > >     int16_t v8_int16[8];
 > >     int8_t v16_int8[16];
 > > }
 > > 
 > > Then the following code in c-valprint.c causes it to be printed as a 
 > > string:
 > > 
 > >           /* For an array of chars, print with string syntax.  */
 > >           if (eltlen == 1 &&
 > >               ((TYPE_CODE (elttype) == TYPE_CODE_INT)
 > >                || ((current_language->la_language == language_m2)
 > >                    && (TYPE_CODE (elttype) == TYPE_CODE_CHAR)))
 > >               && (format == 0 || format == 's'))
 > > 
 > > You could probably make a good case that arrays of 'int' should be 
 > > printed as you describe, but that's a debate I'll leave to someone else.
 > 
 > Ah, you're right.  Thanks for the detail.
 > 

And you haven't noticed this comment in the testfile, I take it :-) I
discovered this while writing the vector support, but didn't fix it. I
don't know that it actually needs to be fixed. It's a feature, not a
bug, one could argue.

# Note: in LE case, the char array is printed WITHOUT the last character.
# Gdb treats the terminating null char in the array like the terminating
# null char in a string and doesn't print it. This is not a failure, but
# the way gdb works.

Elena


 > Otherwise, I like Klee's patch... anyone else?
 > 
 > -- 
 > Daniel Jacobowitz
 > MontaVista Software                         Debian GNU/Linux Developer

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

[Klee Dienes]

I think it's definitely a misfeature.  It's would be different if GDB 
were skipping all the trailing nulls, and not just the final null ... 
but either way, I think it's the wrong behavior.  An array is an array, 
not a string, and printing:

$1 = "abcd\000\000\000\000\000"

instead of

$1 = "abcd\000\000\000\000\000\000"

for 'char buf[10] = "hello"'

just seems much more confusing than useful.

On Friday, October 18, 2002, at 07:20 PM, Elena Zannoni wrote:
>
> And you haven't noticed this comment in the testfile, I take it :-) I
> discovered this while writing the vector support, but didn't fix it. I
> don't know that it actually needs to be fixed. It's a feature, not a
> bug, one could argue.
>
> # Note: in LE case, the char array is printed WITHOUT the last 
> character.
> # Gdb treats the terminating null char in the array like the 
> terminating
> # null char in a string and doesn't print it. This is not a failure, 
> but
> # the way gdb works.
>
> Elena

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

[Daniel Jacobowitz]

I absolutely agree.  I ran into this a couple of days ago and wasted
ten minutes figuring out how big my array was again, anyway...

On Mon, Nov 04, 2002 at 11:02:03PM -0500, Klee Dienes wrote:
> I think it's definitely a misfeature.  It's would be different if GDB 
> were skipping all the trailing nulls, and not just the final null ... 
> but either way, I think it's the wrong behavior.  An array is an array, 
> not a string, and printing:
> 
> $1 = "abcd\000\000\000\000\000"
> 
> instead of
> 
> $1 = "abcd\000\000\000\000\000\000"
> 
> for 'char buf[10] = "hello"'
> 
> just seems much more confusing than useful.
> 
> On Friday, October 18, 2002, at 07:20 PM, Elena Zannoni wrote:
> >
> >And you haven't noticed this comment in the testfile, I take it :-) I
> >discovered this while writing the vector support, but didn't fix it. I
> >don't know that it actually needs to be fixed. It's a feature, not a
> >bug, one could argue.
> >
> ># Note: in LE case, the char array is printed WITHOUT the last 
> >character.
> ># Gdb treats the terminating null char in the array like the 
> >terminating
> ># null char in a string and doesn't print it. This is not a failure, 
> >but
> ># the way gdb works.
> >
> >Elena
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Eli Zaretskii]

> Date: Fri, 4 Oct 2002 16:41:48 -0400
> From: Klee Dienes <klee@mit.edu>
> 
> 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.

Thanks for this contribution.  If it is approved, please also change
the relevant parts of the user manual to reflect this change.

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

[Klee Dienes]

The only relevant part of the documentation I noticed was the following:

> Some registers have distinct ``raw'' and ``virtual'' data formats.  
> This
> means that the data format in which the register contents are saved by
> the operating system is not the same one that your program normally
> sees.  For example, the registers of the 68881 floating point
> coprocessor are always saved in ``extended'' (raw) format, but all C
> programs expect to work with ``double'' (virtual) format.  In such
> cases, @value{GDBN} normally works with the virtual format only (the 
> format
> that makes sense for your program), but the @code{info registers} 
> command
> prints the data in both formats.

Fortunately for me, that's exactly what my patch modifies GDB to do 
(although according my interpretation of the documentation, I should 
really be testing for (TYPE_CODE_INT) and not (TYPE_CODE_FLOAT || 
TYPE_VECTOR).  But in practice I suspect the two cases are the same.

The following documentation patch isn't really related to my patch, but 
would probably be a good idea regardless:

diff -u -r1.23 gdb.texinfo
--- gdb.texinfo 2002/09/27 00:36:40     1.23
+++ gdb.texinfo 2002/10/05 20:06:50
@@ -5559,14 +5559,14 @@
  @table @code
  @kindex info registers
  @item info registers
-Print the names and values of all registers except floating-point
-registers (in the selected stack frame).
+Print the names and values of all registers except floating-point and
+vector registers (in the selected stack frame).

  @kindex info all-registers
  @cindex floating point registers
  @item info all-registers
  Print the names and values of all registers, including floating-point
-registers.
+and vector registers.

  @item info registers @var{regname} @dots{}
  Print the @dfn{relativized} value of each specified register 
@var{regname}.

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

[Eli Zaretskii]

> Date: Sat, 5 Oct 2002 16:03:44 -0400
> From: Klee Dienes <klee@apple.com>
> 
> The following documentation patch isn't really related to my patch, but 
> would probably be a good idea regardless:
> 
> diff -u -r1.23 gdb.texinfo
> --- gdb.texinfo 2002/09/27 00:36:40     1.23
> +++ gdb.texinfo 2002/10/05 20:06:50
> @@ -5559,14 +5559,14 @@
>   @table @code
>   @kindex info registers
>   @item info registers
> -Print the names and values of all registers except floating-point
> -registers (in the selected stack frame).
> +Print the names and values of all registers except floating-point and
> +vector registers (in the selected stack frame).
> 
>   @kindex info all-registers
>   @cindex floating point registers
>   @item info all-registers
>   Print the names and values of all registers, including floating-point
> -registers.
> +and vector registers.

Thanks, this is approved.

Do we have facilities for printing vector registers?  If so, we should
probably add a cross-reference to their description here.  The
intersted reader will most probably wonder what can she do to print
vector registers when she reads these passages.

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

[Klee Dienes]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> Thanks, this is approved.
>
> Do we have facilities for printing vector registers?  If so, we should
> probably add a cross-reference to their description here.  The
> intersted reader will most probably wonder what can she do to print
> vector registers when she reads these passages.

The closest facility is the 'info vector' command, which by default 
prints the contents of all vector registers, but is documented simply 
as "Print the status of the vector unit.", which I take to mean that it 
can be overridden to have arch-specific output, much like 'info float'. 
  An 'info vector-registers' and 'info fp-registers' command might not 
be such a bad idea, but none exists at the moment that I know of.

We'll also probably need to look at the following chunk of 
documentation if/when this patch is accepted:

> @value{GDBN} always considers the contents of an ordinary register as 
> an
> integer when the register is examined in this way.  Some machines have
> special registers which can hold nothing but floating point; these
> registers are considered to have floating point values.  There is no 
> way
> to refer to the contents of an ordinary register as floating point 
> value
> (although you can @emph{print} it as a floating point value with
> @samp{print/f $@var{regname}}).

Maybe something along the lines of:

@value{GDBN} always considers the contents of an ordinary register as an
integer when the register is examined in this way.  Some machines have
special registers that are predefined to have specific types (typically 
floating
point or vector registers); these registers are printed according to 
their
system-defined type.  There is no way to refer to the contents of an 
ordinary
register as a floating point value or vector type (although you can 
@emph{print}
it as a floating point value with @samp{print/f $@var{regname}}).

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

[Eli Zaretskii]

> Date: Fri, 11 Oct 2002 12:26:02 -0400
> From: Klee Dienes <klee@apple.com>
> 
> Maybe something along the lines of:
> 
> @value{GDBN} always considers the contents of an ordinary register as an
> integer when the register is examined in this way.  Some machines have
> special registers that are predefined to have specific types (typically 
> floating
> point or vector registers); these registers are printed according to 
> their
> system-defined type.  There is no way to refer to the contents of an 
> ordinary
> register as a floating point value or vector type (although you can 
> @emph{print}
> it as a floating point value with @samp{print/f $@var{regname}}).

That's good, but perhaps an explicit reference to "info vector" and
"info float" would be useful.

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

[Andrew Cagney]

> Eli Zaretskii <eliz@is.elta.co.il> writes:
> 
>> Thanks, this is approved.
>> 
>> Do we have facilities for printing vector registers?  If so, we should
>> probably add a cross-reference to their description here.  The
>> intersted reader will most probably wonder what can she do to print
>> vector registers when she reads these passages.

> 
> The closest facility is the 'info vector' command, which by default prints the contents of all vector registers, but is documented simply as "Print the status of the vector unit.", which I take to mean that it can be overridden to have arch-specific output, much like 'info float'.  An 'info vector-registers' and 'info fp-registers' command might not be such a bad idea, but none exists at the moment that I know of.

The wording was lifted from ``info float''.  The assumption is that the 
architecture backend will eventually find it necessary customize these 
commands.  For the architectures I've looked at (Intel's SSE and WMMX) 
an ``info vector'' command ends up needing to print both true vector 
registers and some associated status registers.  The (er now legendary) 
reggroups code addresses much of this problem.

I don't think we need ``info fp-registers'' or ``info vector-registers'' 
commands.

Andrew

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

[Elena Zannoni]

[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

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

[Klee Dienes]

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

You're right about the problems with my patch to the test suite.  I was 
trying to separate out my vector-printing changes from the part of the 
patch that I submitted under a separate RFA ("Support Altivec tests on 
Mac OS X"), and didn't do a very good job of it.

I've attached a complete version of our altivec-regs.exp, including the 
parts already submitted under the separate RFA.  I changed "info 
powerpc altivec" to "info vector" and moved the set of hex_vector, 
though I'd argue it's not really all that far away from the usage when 
it's next to the set of decimal_vector, will be even closer if we fix 
the "skip the trailing null" business, and it's handy to have them next 
to each other for comparison.

I wasn't able to test the last part of the patch, about matching the 
vrsave and vscr in the output of "info vector", as our "info vector" 
only lists the vector registers themselves (I'll fix when I covert our 
code to use the new reggroups support in a week or so).


[-- Attachment #2: altivec-registers.txt --]
[-- Type: text/plain, Size: 5348 bytes --]

--- /Volumes/Storage/Users/kdienes/source/cygnus.cygnus/src/gdb/testsuite/gdb.arch/altivec-regs.exp	Tue Nov  5 02:38:07 2002
+++ altivec-regs.exp	Tue Nov  5 03:43:51 2002
@@ -32,7 +32,13 @@
 set prms_id 0
 set bug_id 0
 
-if ![istarget "powerpc-*"] then {
+if [istarget "powerpc-apple-*"] {
+    set vrbase "v"
+    set compile_flags { debug additional_flags=-w additional_flags=-faltivec }
+} elseif [istarget "powerpc-*"] {
+    set vrbase "vr"
+    set compile_flags { debug additional_flags=-w }
+} else {
     verbose "Skipping altivec register tests."
     return
 }
@@ -41,7 +47,7 @@
 set binfile ${objdir}/${subdir}/${testfile}
 set src1 ${srcdir}/${subdir}/${testfile}.c
 
-if  { [gdb_compile ${src1} ${binfile} executable {debug additional_flags=-w}] != "" } {
+if  { [gdb_compile ${src1} ${binfile} executable ${compile_flags}] != "" } {
      gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
 }
 
@@ -60,7 +66,7 @@
 # set all the registers integer portions to 1
 for {set i 0} {$i < 32} {incr i 1} {
         for {set j 0} {$j < 4} {incr j 1} {
-           gdb_test "set \$vr$i.v4_int32\[$j\] = 1" "" "set reg vr$i.v4si.f\[$j\]"
+           gdb_test "set \$$vrbase$i.v4_int32\[$j\] = 1" "" "set reg $vrbase$i.v4si.f\[$j\]"
         }
 }
 
@@ -88,17 +94,17 @@
 # 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 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 = ..00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.001.."
 } 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 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.00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.001.00*.00*.."
 }
 
 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 $vrbase$i" "$vrbase$i.*$decimal_vector\t\\(raw 0x00000001000000010000000100000001\\)" "info reg $vrbase$i"
 }
 
-gdb_test "info reg vrsave" "vrsave.*0x1" "info reg vrsave"
-gdb_test "info reg vscr" "vscr.*0x1" "info reg vscr"
+gdb_test "info reg vrsave" "vrsave.*0x1\t1" "info reg vrsave"
+gdb_test "info reg vscr" "vscr.*0x1\t1" "info reg vscr"
 
 # Now redo the same tests, but using the print command.
 # Note: in LE case, the char array is printed WITHOUT the last character.
@@ -107,25 +113,29 @@
 # 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.."
+    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 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.."
+    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.."
+}
+
+for {set i 0} {$i < 32} {incr i 1} {
+        gdb_test "print \$$vrbase$i" ".* = $decimal_vector" "print $vrbase$i (natural) $r3067302"
 }
 
 for {set i 0} {$i < 32} {incr i 1} {
-        gdb_test "print \$vr$i" ".* = $decimal_vector" "print vr$i"
+        gdb_test "print /x \$$vrbase$i" ".* = $hex_vector" "print $vrbase$i (hex) $r3067302"
 }
 
 gdb_test "print \$vrsave" ".* = 1" "print vrsave"
 gdb_test "print \$vscr" ".* = 1" "print vscr"
 
 for {set i 0} {$i < 32} {incr i 1} {
-         set pattern$i ".*vr$i.*"
-         append pattern$i $vector_register
+         set pattern$i ".*$vrbase$i.*"
+         append pattern$i $decimal_vector
 }
 
-send_gdb "info powerpc altivec\n"
-gdb_expect_list "info powerpc altivec" ".*$gdb_prompt $" {
+send_gdb "info vector\n"
+gdb_expect_list "info vector" ".*$gdb_prompt $" {
 [$pattern0]
 [$pattern1]
 [$pattern2]
@@ -158,8 +168,8 @@
 [$pattern29]
 [$pattern30]
 [$pattern31]
-"\[ \t\n\r\]+vscr\[ \t\]+0x1"
-"\[ \t\n\r\]+vrsave\[ \t\]+0x1"
+"\[ \t\n\r\]+vscr\[ \t\]+0x1\t1"
+"\[ \t\n\r\]+vrsave\[ \t\]+0x1\t1"
 }
 
 gdb_test "break vector_fun" \

[-- Attachment #3: altivec-regs.exp --]
[-- Type: application/octet-stream, Size: 7686 bytes --]

# Copyright (C) 2002 Free Software Foundation, Inc.
# 
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, 
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
# Please email any bugs, comments, and/or additions to this file to:
# bug-gdb@prep.ai.mit.edu
#

# Tests for Powerpc AltiVec register setting and fetching

if $tracelevel then {
    strace $tracelevel
}

#
# Test the use of registers, especially AltiVec registers, for Powerpc.
# This file uses altivec-regs.c for input.
#

set prms_id 0
set bug_id 0

if [istarget "powerpc-apple-*"] {
    set vrbase "v"
    set compile_flags { debug additional_flags=-w additional_flags=-faltivec }
} elseif [istarget "powerpc-*"] {
    set vrbase "vr"
    set compile_flags { debug additional_flags=-w }
} else {
    verbose "Skipping altivec register tests."
    return
}

set testfile "altivec-regs"
set binfile ${objdir}/${subdir}/${testfile}
set src1 ${srcdir}/${subdir}/${testfile}.c

if  { [gdb_compile ${src1} ${binfile} executable ${compile_flags}] != "" } {
     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
}

gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

#
# Run to `main' where we begin our tests.
#

if ![runto_main] then {
    gdb_suppress_tests
}

# set all the registers integer portions to 1
for {set i 0} {$i < 32} {incr i 1} {
        for {set j 0} {$j < 4} {incr j 1} {
           gdb_test "set \$$vrbase$i.v4_int32\[$j\] = 1" "" "set reg $vrbase$i.v4si.f\[$j\]"
        }
}

gdb_test "set \$vscr = 1" "" ""
gdb_test "set \$vrsave = 1" "" ""

# Now execute some target code, so that GDB's register cache is flushed.

gdb_test "next" "" ""

send_gdb "show endian\n"
gdb_expect {
    -re "(The target endianness is set automatically .currently )(big|little)( endian.*)$gdb_prompt $" {
        pass "endianness"
	set endianness $expect_out(2,string)
    }
    -re ".*$gdb_prompt $" {
	fail "couldn't get endianness"
    }
    timeout		{ fail "(timeout) endianness" }
}

# And then read the AltiVec registers back, to see that
# a) the register write above worked, and
# b) the register read (below) also 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 = ..00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.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.00*.00*.00*.001.00*.00*.00*.001.00*.00*.00*.001.00*.00*.."
}

for {set i 0} {$i < 32} {incr i 1} {
        gdb_test "info reg $vrbase$i" "$vrbase$i.*$decimal_vector\t\\(raw 0x00000001000000010000000100000001\\)" "info reg $vrbase$i"
}

gdb_test "info reg vrsave" "vrsave.*0x1\t1" "info reg vrsave"
gdb_test "info reg vscr" "vscr.*0x1\t1" "info reg vscr"

# Now redo the same tests, but using the print command.
# Note: in LE case, the char array is printed WITHOUT the last character.
# Gdb treats the terminating null char in the array like the terminating
# null char in a string and doesn't print it. This is not a failure, but
# the way gdb works.

if {$endianness == "big"} {
    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 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.."
}

for {set i 0} {$i < 32} {incr i 1} {
        gdb_test "print \$$vrbase$i" ".* = $decimal_vector" "print $vrbase$i (natural) $r3067302"
}

for {set i 0} {$i < 32} {incr i 1} {
        gdb_test "print /x \$$vrbase$i" ".* = $hex_vector" "print $vrbase$i (hex) $r3067302"
}

gdb_test "print \$vrsave" ".* = 1" "print vrsave"
gdb_test "print \$vscr" ".* = 1" "print vscr"

for {set i 0} {$i < 32} {incr i 1} {
         set pattern$i ".*$vrbase$i.*"
         append pattern$i $decimal_vector
}

send_gdb "info vector\n"
gdb_expect_list "info vector" ".*$gdb_prompt $" {
[$pattern0]
[$pattern1]
[$pattern2]
[$pattern3]
[$pattern4]
[$pattern5]
[$pattern6]
[$pattern7]
[$pattern8]
[$pattern9]
[$pattern10]
[$pattern11]
[$pattern12]
[$pattern13]
[$pattern14]
[$pattern15]
[$pattern16]
[$pattern17]
[$pattern18]
[$pattern19]
[$pattern20]
[$pattern21]
[$pattern22]
[$pattern23]
[$pattern24]
[$pattern25]
[$pattern26]
[$pattern27]
[$pattern28]
[$pattern29]
[$pattern30]
[$pattern31]
"\[ \t\n\r\]+vscr\[ \t\]+0x1\t1"
"\[ \t\n\r\]+vrsave\[ \t\]+0x1\t1"
}

gdb_test "break vector_fun" \
 "Breakpoint 2 at.*altivec-regs.c, line \[0-9\]+\\." \
 "Set breakpoint at vector_fun"

# Actually it is nuch easier to see these results printed in hex.
gdb_test "set output-radix 16" \
  "Output radix now set to decimal 16, hex 10, octal 20." \
  "Set output radix to hex"

gdb_test "continue" \
  "Breakpoint 2, vector_fun .a=.0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe., b=.0x1010101, 0x1010101, 0x1010101, 0x1010101.*altivec-regs.c.*vec_splat_u8.2..;" \
  "continue to vector_fun"

# Do a next over the assignment to vector 'a'. 
gdb_test "next" ".*b = \\(\\(vector unsigned int\\) vec_splat_u8\\(3\\)\\);" \
  "next (1)"

# Do a next over the assignment to vector 'b'. 
gdb_test "next" "c = vec_add \\(a, b\\);" \
  "next (2)"

# Now 'a' should be '0x02020202...' and 'b' should be '0x03030303...'
gdb_test "print/x a" \
  ".*= .0x2020202, 0x2020202, 0x2020202, 0x2020202." \
  "print vector parameter a"

gdb_test "print/x b" \
  ".*= .0x3030303, 0x3030303, 0x3030303, 0x3030303." \
  "print vector parameter b"

# If we do an 'up' now, and print 'x' and 'y' we should see the values they
# have in main, not the values they have in vector_fun.
gdb_test "up" ".1.*main \\(\\) at.*altivec-regs.c.*z = vector_fun \\(x, y\\);" \
  "up to main"

gdb_test "print/x x" \
  ".*= .0xfefefefe, 0xfefefefe, 0xfefefefe, 0xfefefefe." \
  "print vector x"

gdb_test "print/x y" \
  ".*= .0x1010101, 0x1010101, 0x1010101, 0x1010101." \
  "print vector y"

# now go back to vector_func and do a finish, to see if we can print the return
# value correctly.

gdb_test "down" \
  ".0  vector_fun \\(a=.0x2020202, 0x2020202, 0x2020202, 0x2020202., b=.0x3030303, 0x3030303, 0x3030303, 0x3030303.\\) at.*altivec-regs.c.*c = vec_add \\(a, b\\);" \
  "down to vector_fun"

gdb_test "finish" \
  "Run till exit from .0  vector_fun \\(a=.0x2020202, 0x2020202, 0x2020202, 0x2020202., b=.0x3030303, 0x3030303, 0x3030303, 0x3030303.\\) at.*altivec-regs.c.*in main \\(\\) at.*altivec-regs.c.*z = vector_fun \\(x, y\\);.*Value returned is.*= .0x5050505, 0x5050505, 0x5050505, 0x5050505." \
  "finish returned correct value"




[-- Attachment #4: Type: text/plain, Size: 4372 bytes --]




On Friday, October 18, 2002, at 07:34 PM, Elena Zannoni wrote:
>
> 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
>