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

Elena Zannoni
2002-10-18T23:37:29Z

[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