Fix scm-ports.exp regression
authorTom Tromey <tom@tromey.com>
Wed, 3 Jan 2018 18:12:34 +0000 (11:12 -0700)
committerTom Tromey <tom@tromey.com>
Mon, 15 Jan 2018 18:51:29 +0000 (11:51 -0700)
commit86d6a90c58ee3fb924bcbca154f4e32347437e6c
treed1d035a937d11bfe87ef1e96034c0c49e02b0dab
parent930b5f8bfb8e2d971f459c570d248714183a08d5
Fix scm-ports.exp regression

In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.

What happens is that on x86, this:

set sp_reg [get_integer_valueof "\$sp" 0]

... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":

    print /d $sp
    $1 = -11496

Then later the test suite does:

    gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
"= $sp_reg" \
"seek to \$sp"

... expecting this value to be identical to the saved $sp_reg value.
However it gets:

    guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
    = 4294955800

"print" is just a wrapper for guile's format:

    gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"

The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.

Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.

2018-01-15  Tom Tromey  <tom@tromey.com>

* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
compute sp_reg.
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.guile/scm-ports.exp