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


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: altivec-registers.txt
Description: Text document

Attachment: altivec-regs.exp
Description: Binary data



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







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