[pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch

[pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch

[Andreas Arnez]

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(-)

diff --git a/gdb/testsuite/gdb.arch/s390-vregs.exp b/gdb/testsuite/gdb.arch/s390-vregs.exp
index 078c153..d2c31e1 100644
--- a/gdb/testsuite/gdb.arch/s390-vregs.exp
+++ b/gdb/testsuite/gdb.arch/s390-vregs.exp
@@ -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
-- 
2.5.0

Re: [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch

[Tom Tromey]

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

Re: [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch

[Andreas Arnez]

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