From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10895 invoked by alias); 18 Oct 2002 23:37:29 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10878 invoked from network); 18 Oct 2002 23:37:28 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 18 Oct 2002 23:37:28 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g9INGRw28673 for ; Fri, 18 Oct 2002 19:16:27 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9INbRf18672 for ; Fri, 18 Oct 2002 19:37:27 -0400 Received: from localhost.redhat.com (IDENT:r3jEuuYOWXexSHGnbJF+TT6w8JpzYEBu@tooth.toronto.redhat.com [172.16.14.29]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g9INbQT17547 for ; Fri, 18 Oct 2002 19:37:26 -0400 Received: by localhost.redhat.com (Postfix, from userid 469) id 46458FF79; Fri, 18 Oct 2002 19:34:46 -0400 (EDT) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <15792.39573.382062.591516@localhost.redhat.com> Date: Fri, 18 Oct 2002 16:37:00 -0000 To: Klee Dienes Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Print vector registers in natural format, not hex In-Reply-To: References: X-SW-Source: 2002-10/txt/msg00315.txt.bz2 [Klee, your mailer is officially weird.] > The current GDB behavior for 'info reg' is the following: >=20 > Print all floating types in natural form, followed by "(raw 0xffffffff)"= .=20 > Print all other types in hex; for non-vector types, additionally print t= he > 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 r= ead. >=20 > 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 t= he > results from running the testsuite on powerpc-apple-darwin or > i386-unknown-gnu-linux; it does require a testsuite change to altivec-re= gs.exp > on powerpc-unknown-gnu-linux. >=20 > (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 le= ft > that part of the behavior unchanged.) >=20 > Before: >=20 > (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 =3D 0x606162636465666740490fdb402df854,=20 > v4_float =3D {0xffffffff, 0xffffffff, 0x3, 0x2},=20 > v4_int32 =3D {0x60616263, 0x64656667, 0x40490fdb, 0x402df854},=20 > v8_int16 =3D {0x6061, 0x6263, 0x6465, 0x6667, 0x4049, 0xfdb, 0x402d, 0xf= 854},=20 > v16_int8 =3D {0x60, 0x61, 0x62, 0x63, 0x64, 0x65, 0x66, 0x67, 0x40, 0x49= , 0xf, > 0xdb, 0x40, 0x2d, 0xf8, 0x54} > } >=20 > (gdb) show architecture > The target architecture is set automatically (currently i386) > (gdb) info reg xmm0 > xmm0 { > v4_float =3D {0x2, 0x3, 0x1, 0x0},=20 > v2_double =3D {0x32, 0x0},=20 > v16_int8 =3D {0x54, 0xf8, 0x2d, 0x40, 0xdb, 0xf, 0x49, 0x40, 0x3b, 0xaa,= 0xb8, > 0x3f,=20 > 0x18, 0x72, 0x31, 0x3f},=20 > v8_int16 =3D {0xf854, 0x402d, 0xfdb, 0x4049, 0xaa3b, 0x3fb8, 0x7218, 0x3= f31},=20 > v4_int32 =3D {0x402df854, 0x40490fdb, 0x3fb8aa3b, 0x3f317218},=20 > v2_int64 =3D {0x40490fdb402df854, 0x3f3172183fb8aa3b},=20 > uint128 =3D 0x3f3172183fb8aa3b40490fdb402df854 > } >=20 > After: >=20 > (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 =3D 0x606162636465666740490fdb402df854,=20 > v4_float =3D {6.49626082e+19, 1.6926733e+22, 3.14159274, 2.71828175},=20 > v4_int32 =3D {1616994915, 1684366951, 1078530011, 1076754516},=20 > v8_int16 =3D {24673, 25187, 25701, 26215, 16457, 4059, 16429, -1964},=20 > v16_int8 =3D "`abcdefg@I\017=A2XZ@-=A2XZT" > } (raw 0x606162636465666740490fdb402df854) >=20 > (gdb) show architecture > The target architecture is set automatically (currently i386) > (gdb) info reg xmm0 > xmm0 { > v4_float =3D {2.71828175, 3.14159274, 1.44269502, 0.693147182},=20 > v2_double =3D {50.12387850041037, 0.00026619998945657018},=20 > v16_int8 =3D "T=A1Z-@=A1Z\017I@;=A1Z=A1Z?\030r1?",=20 > v8_int16 =3D {-1964, 16429, 4059, 16457, -21957, 16312, 29208, 16177},=20 > v4_int32 =3D {1076754516, 1078530011, 1069066811, 1060205080},=20 > v2_int64 =3D {4632251126076274772, 4553546146722130491},=20 > uint128 =3D 0x3f3172183fb8aa3b40490fdb402df854 > } (raw 0x3f3172183fb8aa3b40490fdb402df854) >=20 > The patch: >=20 > 2002-10-04 Klee Dienes >=20 > * 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. >=20 > 2004-10-04 Klee Dienes >=20 > * gdb.arch/altivec-regs.exp: Info reg now prints in natural, not > hex, format. >=20 > Index: infcmd.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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)); > } >=20 > - /* If virtual format is floating, print it that way, and in raw > - hex. */ > - if (TYPE_CODE (REGISTER_VIRTUAL_TYPE (i)) =3D=3D 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)) =3D=3D TYPE_CODE_FLT) > + || TYPE_VECTOR (REGISTER_VIRTUAL_TYPE (i))) > { > int j; >=20 > @@ -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)) =3D=3D 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); > } >=20 > /* The SPARC wants to print even-numbered float regs as doubles >=20 The above portion of the patch seems reasonable to me.=20 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 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 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. >=20 > if {$endianness =3D=3D "big"} { > -set vector_register ".uint128 =3D 0x00000001000000010000000100000001, v= 4_float > =3D .0x0, 0x0, 0x0, 0x0., v4_int32 =3D .0x1, 0x1, 0x1, 0x1., v8_int16 = =3D .0x0, 0x1, > 0x0, 0x1, 0x0, 0x1, 0x0, 0x1., v16_int8 =3D .0x0, 0x0, 0x0, 0x1, 0x0, 0x= 0, 0x0, > 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.." > +set hex_vector ".uint128 =3D 0x00000001000000010000000100000001, v4_flo= at =3D > .0x0, 0x0, 0x0, 0x0., v4_int32 =3D .0x1, 0x1, 0x1, 0x1., v8_int16 =3D .0= x0, 0x1, > 0x0, 0x1, 0x0, 0x1, 0x0, 0x1., v16_int8 =3D .0x0, 0x0, 0x0, 0x1, 0x0, 0x= 0, 0x0, > 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0, 0x1.." > } else { > -set vector_register ".uint128 =3D 0x00000001000000010000000100000001, v= 4_float > =3D .0x0, 0x0, 0x0, 0x0., v4_int32 =3D .0x1, 0x1, 0x1, 0x1., v8_int16 = =3D .0x1, 0x0, > 0x1, 0x0, 0x1, 0x0, 0x1, 0x0., v16_int8 =3D .0x1, 0x0, 0x0, 0x0, 0x1, 0x= 0, 0x0, > 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.." > +set hex_vector ".uint128 =3D 0x00000001000000010000000100000001, v4_flo= at =3D > .0x0, 0x0, 0x0, 0x0., v4_int32 =3D .0x1, 0x1, 0x1, 0x1., v8_int16 =3D .0= x1, 0x0, > 0x1, 0x0, 0x1, 0x0, 0x1, 0x0., v16_int8 =3D .0x1, 0x0, 0x0, 0x0, 0x1, 0x= 0, 0x0, > 0x0, 0x1, 0x0, 0x0, 0x0, 0x1, 0x0, 0x0, 0x0.." > +} > + > +if {$endianness =3D=3D "big"} { > + set decimal_vector ".uint128 =3D 0x0000000100000001000000010000000= 1, > v4_float =3D .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 =3D .1, 1, 1= , 1., > v8_int16 =3D .0, 1, 0, 1, 0, 1, 0, 1., v16_int8 =3D > ..0.0.0.001.0.0.0.001.0.0.0.001.0.0.0.001.." > +} else { > + set decimal_vector ".uint128 =3D 0x0000000100000001000000010000000= 1, > v4_float =3D .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 =3D .1, 1, 1= , 1., > v8_int16 =3D .1, 0, 1, 0, 1, 0, 1, 0., v16_int8 =3D > ..001.0.0.0.001.0.0.0.001.0.0.0.001.0.0.." > } >=20 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" > } >=20 > 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. >=20 > -if {$endianness =3D=3D "big"} { > - set decimal_vector ".uint128 =3D 0x0000000100000001000000010000000= 1, > v4_float =3D .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 =3D .1, 1, 1= , 1., > v8_int16 =3D .0, 1, 0, 1, 0, 1, 0, 1., v16_int8 =3D > ..0.0.0.001.0.0.0.001.0.0.0.001.0.0.0.001.." > -} else { > - set decimal_vector ".uint128 =3D 0x0000000100000001000000010000000= 1, > v4_float =3D .1.*e-45, 1.*e-45, 1.*e-45, 1.*e-45., v4_int32 =3D .1, 1, 1= , 1., > v8_int16 =3D .1, 0, 1, 0, 1, 0, 1, 0., v16_int8 =3D > ..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" ".* =3D $decimal_vector" "print vr$i" > + gdb_test "print /x \$vr$i" ".* =3D $hex_decimal_vector" "print = vr$i" ^^^^^^^^^^^^^^^^^^^ How could this work?=20 > } >=20 > gdb_test "print \$vrsave" ".* =3D 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