[pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch
Commit Message
s390-vregs.exp yields a Tcl error:
ERROR: can't read "i": no such variable
while executing
"expr $a_high * ($i + 1) * $a_high "
(procedure "hex128" line 2)
invoked from within
"hex128 $a_high $a_low $b_high $b_low"
...
This is a regression, caused by commit 30a254669b16b8 -- "Don't always
zero pad in print_*_chars". That patch introduced a new procedure
"hex128" for formatting a 128-bit value as hex, but it accidentally moved
the calculation of the 128-bit value into that new procedure as well
instead of leaving it in the original context. This is fixed.
gdb/testsuite/ChangeLog:
* gdb.arch/s390-vregs.exp: Calculate parameters to hex128 in the
calling context.
(hex128): Drop erroneous calculation of parameters.
---
gdb/testsuite/gdb.arch/s390-vregs.exp | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
Comments
>>>>> "Andreas" == Andreas Arnez <arnez@linux.vnet.ibm.com> writes:
Andreas> This is a regression, caused by commit 30a254669b16b8 -- "Don't always
Andreas> zero pad in print_*_chars". That patch introduced a new procedure
Andreas> "hex128" for formatting a 128-bit value as hex, but it accidentally moved
Andreas> the calculation of the 128-bit value into that new procedure as well
Andreas> instead of leaving it in the original context. This is fixed.
Thanks. I'm sorry about that. I try not to make mistakes like this by
running all my changes through the buildbot, but either it didn't report
this, or I misread the results.
Tom
On Mon, Jul 31 2017, Tom Tromey wrote:
>>>>>> "Andreas" == Andreas Arnez <arnez@linux.vnet.ibm.com> writes:
>
> Andreas> This is a regression, caused by commit 30a254669b16b8 -- "Don't always
> Andreas> zero pad in print_*_chars". That patch introduced a new procedure
> Andreas> "hex128" for formatting a 128-bit value as hex, but it accidentally moved
> Andreas> the calculation of the 128-bit value into that new procedure as well
> Andreas> instead of leaving it in the original context. This is fixed.
>
> Thanks. I'm sorry about that. I try not to make mistakes like this by
> running all my changes through the buildbot, but either it didn't report
> this, or I misread the results.
Sure, no problem.
Note that this test only runs on systems with a vector facility. And
even then your patch didn't cause additional FAILs, but a Tcl error
instead.
--
Andreas
@@ -147,14 +147,12 @@ gdb_continue_to_breakpoint "change vrs"
set vregs [capture_command_output "info registers vector" ""]
# Format a 128-bit value, given individual 4-byte values, as hex.
-# Leading zeros are suppressed.
+# Suppress leading zeros.
proc hex128 {a_high a_low b_high b_low} {
- set result [format %08x%08x%08x%08x \
- [expr $a_high * ($i + 1) * $a_high ] \
- [expr $a_low * ($i + 1) * $a_low ] \
- [expr $b_high * (32 - $i) * $b_high * 32] \
- [expr $b_low * (32 - $i) * $b_low * 32] ]
- return [regsub -- "^0*" $result ""]
+ set result [format "%x%08x%08x%08x" $a_high $a_low $b_high $b_low]
+ regsub -- "^0*" $result "" result
+ if { $result eq "" } { set result 0 }
+ return $result
}
set j 1
@@ -162,7 +160,11 @@ foreach {- r i val} [regexp -all -inline -line \
{^(\D*)(\d+)\s+.*?uint128 = 0x([0-9a-f]+?)} $vregs] {
if { $r ne "v" } {
fail "info registers vector: bad line $j"
- } elseif { $val ne [hex128 $a_high $a_low $b_high $b_low] } {
+ } elseif { $val ne [hex128 \
+ [expr $a_high * ($i + 1) * $a_high ] \
+ [expr $a_low * ($i + 1) * $a_low ] \
+ [expr $b_high * (32 - $i) * $b_high * 32] \
+ [expr $b_low * (32 - $i) * $b_low * 32] ] } {
fail "compare \$v$i"
}
incr j 1