* [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch
@ 2017-07-24 16:38 Andreas Arnez
2017-07-31 22:10 ` Tom Tromey
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Arnez @ 2017-07-24 16:38 UTC (permalink / raw)
To: gdb-patches; +Cc: Tom Tromey
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch
2017-07-24 16:38 [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch Andreas Arnez
@ 2017-07-31 22:10 ` Tom Tromey
2017-08-01 17:57 ` Andreas Arnez
0 siblings, 1 reply; 3+ messages in thread
From: Tom Tromey @ 2017-07-31 22:10 UTC (permalink / raw)
To: Andreas Arnez; +Cc: gdb-patches, 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch
2017-07-31 22:10 ` Tom Tromey
@ 2017-08-01 17:57 ` Andreas Arnez
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Arnez @ 2017-08-01 17:57 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2017-08-01 17:57 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-24 16:38 [pushed] s390-vregs.exp: Fix Tcl error after non-zero-pad patch Andreas Arnez
2017-07-31 22:10 ` Tom Tromey
2017-08-01 17:57 ` Andreas Arnez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).