Re: [RFA] Fix scm-ports.exp regression

[Tom Tromey <tom@tromey.com>]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

>> I think the simplest fix is to use "print/u" rather than "print/d" to
>> get the value of sp_reg in the test case.

Pedro> Can you expand a bit on this rationale, please?

Pedro> There's:
Pedro>  (parse-and-eval \"*(char*) \$sp\")
Pedro> in the context of the diff.  Is that related?  I ask because
Pedro> that "char" in there would look like something that could print
Pedro> as signed or unsigned depending on target.

I don't think that is related.  That expression has a dereference.

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, so I would think that this sort
of printing is handled by guile, not by gdb.

IIRC what happened is that "print/d" slightly changed in some cases
during the scalar printing work, and what we're seeing is the result.

Tom