[RFA] Fix scm-ports.exp regression

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFA] Fix scm-ports.exp regression

Tom Tromey-2
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.

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.

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

2018-01-03  Tom Tromey  <[hidden email]>

        * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
        compute sp_reg.
---
 gdb/testsuite/ChangeLog               | 5 +++++
 gdb/testsuite/gdb.guile/scm-ports.exp | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 500dbddf1c..e3903cca6b 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2018-01-03  Tom Tromey  <[hidden email]>
+
+ * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
+ compute sp_reg.
+
 2018-01-03  Xavier Roirand  <[hidden email]>
 
  * gdb.ada/excep_handle.exp: New testcase.
diff --git a/gdb/testsuite/gdb.guile/scm-ports.exp b/gdb/testsuite/gdb.guile/scm-ports.exp
index 48af5e30e1..04170ef4b8 100644
--- a/gdb/testsuite/gdb.guile/scm-ports.exp
+++ b/gdb/testsuite/gdb.guile/scm-ports.exp
@@ -104,7 +104,7 @@ proc test_mem_port_rw { kind } {
     "get sp reg"
  # Note: Only use $sp_reg for gdb_test result matching, don't use it in
  # gdb commands.  Otherwise transcript.N becomes unusable.
- set sp_reg [get_integer_valueof "\$sp" 0]
+ set sp_reg [get_valueof /u "\$sp" 0]
  gdb_test_no_output "guile (define byte-at-sp (parse-and-eval \"*(char*) \$sp\"))" \
     "save current value at sp"
  # Pass the result of parse-and-eval through value-fetch-lazy!,
--
2.13.6

Reply | Threaded
Open this post in threaded view
|

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

Pedro Alves-7
On 01/03/2018 06:20 PM, Tom Tromey wrote:
> 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.
>
> 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.

Can you expand a bit on this rationale, please?

There's:

 (parse-and-eval \"*(char*) \$sp\")

in the context of the diff.  Is that related?  I ask because
that "char" in there would look like something that could print
as signed or unsigned depending on target.

It'll probably be obvious with a bit more info.

Thanks,
Pedro Alves

>
> Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
> build.
>
> 2018-01-03  Tom Tromey  <[hidden email]>
>
> * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
> compute sp_reg.
> ---
>  gdb/testsuite/ChangeLog               | 5 +++++
>  gdb/testsuite/gdb.guile/scm-ports.exp | 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
> index 500dbddf1c..e3903cca6b 100644
> --- a/gdb/testsuite/ChangeLog
> +++ b/gdb/testsuite/ChangeLog
> @@ -1,3 +1,8 @@
> +2018-01-03  Tom Tromey  <[hidden email]>
> +
> + * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
> + compute sp_reg.
> +
>  2018-01-03  Xavier Roirand  <[hidden email]>
>  
>   * gdb.ada/excep_handle.exp: New testcase.
> diff --git a/gdb/testsuite/gdb.guile/scm-ports.exp b/gdb/testsuite/gdb.guile/scm-ports.exp
> index 48af5e30e1..04170ef4b8 100644
> --- a/gdb/testsuite/gdb.guile/scm-ports.exp
> +++ b/gdb/testsuite/gdb.guile/scm-ports.exp
> @@ -104,7 +104,7 @@ proc test_mem_port_rw { kind } {
>      "get sp reg"
>   # Note: Only use $sp_reg for gdb_test result matching, don't use it in
>   # gdb commands.  Otherwise transcript.N becomes unusable.
> - set sp_reg [get_integer_valueof "\$sp" 0]
> + set sp_reg [get_valueof /u "\$sp" 0]
>   gdb_test_no_output "guile (define byte-at-sp (parse-and-eval \"*(char*) \$sp\"))" \
>      "save current value at sp"
>   # Pass the result of parse-and-eval through value-fetch-lazy!,
>

Reply | Threaded
Open this post in threaded view
|

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

Sourceware - gdb-patches mailing list
In reply to this post by Tom Tromey-2
Tom Tromey writes:
 > 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.
 >
 > 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.
 >
 > Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
 > build.
 >
 > 2018-01-03  Tom Tromey  <[hidden email]>
 >
 > * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
 > compute sp_reg.

LGTM
Reply | Threaded
Open this post in threaded view
|

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

Tom Tromey-2
In reply to this post by Pedro Alves-7
>>>>> "Pedro" == Pedro Alves <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Pedro Alves-7
Hi Tromey,

Sorry for the delay.
On 01/09/2018 06:26 PM, Tom Tromey wrote:

>>>>>> "Pedro" == Pedro Alves <[hidden email]> 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.

I see.  So seemingly this is printing a scm_t_off, which seems to be a
signed 64-bit integer:

 /usr/include/guile/2.0/libguile/scmconfig-32.h:82:typedef int64_t scm_t_int64;
 /usr/include/guile/2.0/libguile/scmconfig-32.h:119:typedef scm_t_int64 scm_t_off;
 /usr/include/guile/2.0/libguile/scmconfig-64.h:82:typedef int64_t scm_t_int64;
 /usr/include/guile/2.0/libguile/scmconfig-64.h:119:typedef scm_t_int64 scm_t_off;

while $sp is 32-bit, and we're extracting it as a 32-bit signed
integer (into $sp_reg).

Here:

  (seek rw-mem-port (value->integer sp-reg) SEEK_SET)

"sp-reg" is a pointer, and value->integer takes us to
gdbscm_value_to_integer [I think], which converts the pointer to
an unsigned integer, AFAICT, and then probably that gets cast/converted to
scm_t_off when passed to guile's "seek", somewhere.  And then
'seek' returns the same offset out, as an scm_t_off, and then guile's
'format' prints that.

So pedantically, doing:

"print (scm_t_off) $sp"

   (or really "print (int64_t) $sp",
    or even   "print (long long) $sp"...)

to extract $sp_reg would be a little more to the point, I guess.

But it looks like on 64-bit archs, the API can't access memory
addresses with the high bit set anyway (?) (not sure how to get
those; maybe debugging some bare metal/kernel code), so the
difference doesn't really matter much in practice.

The patch is fine with me as is.  I just wish the commit
log were a little clearer with details such as the above.

> 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.
Yes, before the rework, "/d" would still print integers
as unsigned in some cases.  Now it always prints them as signed,
as if it you wrote something like this:

  (gdb) print (std::make_signed<decltype(EXPR)>::type) EXPR

instead of:

  (gdb) print /d EXPR

with the difference that /d affects display only,
unlike a cast which affects the actual value recorded in
the value history.

Thanks,
Pedro Alves
Reply | Threaded
Open this post in threaded view
|

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

Tom Tromey-2
>>>>> "Pedro" == Pedro Alves <[hidden email]> writes:

Pedro> The patch is fine with me as is.  I just wish the commit
Pedro> log were a little clearer with details such as the above.

I added my explanation to the commit message.
I'm going to push this to the 8.0 branch and trunk.

Tom
Reply | Threaded
Open this post in threaded view
|

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

Sergio Durigan Junior
On Monday, January 15 2018, Tom Tromey wrote:

>>>>>> "Pedro" == Pedro Alves <[hidden email]> writes:
>
> Pedro> The patch is fine with me as is.  I just wish the commit
> Pedro> log were a little clearer with details such as the above.
>
> I added my explanation to the commit message.
> I'm going to push this to the 8.0 branch and trunk.

Hey Tom,

Perhaps you meant to push this to the 8.1 branch?

Thanks,

--
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/
Reply | Threaded
Open this post in threaded view
|

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

Tom Tromey-2
>>>>> "Sergio" == Sergio Durigan Junior <[hidden email]> writes:

Sergio> Perhaps you meant to push this to the 8.1 branch?

Yeah, sorry about that.
I will do it now.
I can revert on the 8.0 branch if someone wants.

Tom
Reply | Threaded
Open this post in threaded view
|

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

Joel Brobecker
> Sergio> Perhaps you meant to push this to the 8.1 branch?
>
> Yeah, sorry about that.
> I will do it now.
> I can revert on the 8.0 branch if someone wants.

I am guessing the patch is correct on the 8.0 branch, even if
there wasn't a fail before. I think it's fine to leave it in.

--
Joel