Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@ericsson.com>,
	"Tedeschi, Walfred" <walfred.tedeschi@intel.com>,
	Simon Marchi <simon.marchi@polymtl.ca>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: [PATCH] Enhance gdb.base/print-file-var.exp testcase (Re: [PATCH V4] symlookup: improves symbol lookup when a file is specified.)
Date: Fri, 20 Oct 2017 15:54:00 -0000	[thread overview]
Message-ID: <99fc3750-dc0d-45a8-d030-e37c0e1a2b77@redhat.com> (raw)
In-Reply-To: <d74ab50a-2308-3c90-c95d-893f0b5134ac@redhat.com>

On 10/20/2017 04:28 PM, Pedro Alves wrote:

> Actually, the patch introduces what looks like a related clear
> regression to me.  With the print-file-var.exp test program, try
> stepping into get_version_2, and printing the this_version_id
> global.  And then type finish.  Vis:
> 
>  (gdb) s
>  get_version_2 () at gdb.base/print-file-var-lib2.c:22
>  22        return this_version_id;
>  (gdb) p this_version_id
>  $1 = 203
>  (gdb) finish
>  Run till exit from #0  get_version_2 () at gdb.base/print-file-var-lib2.c:22
>  0x000000000040073b in main () at gdb.base/print-file-var-main.c:24
>  24        int v2 = get_version_2 ();
>  Value returned is $2 = 104
>  (gdb) 
> 
> GDB says "203", while the program returns "104".
> That looks like a bug to me.  I'd expect the print
> to show me the current value of the variable in scope.
> 
> In current master (without the patch), we get:
> 
>  (gdb) s
>  get_version_2 () at gdb.base/print-file-var-lib2.c:22
>  22        return this_version_id;
>  (gdb) p this_version_id
>  $1 = 104
>  (gdb) finish
>  Run till exit from #0  get_version_2 () at gdb.base/print-file-var-lib2.c:22
>  0x000000000040073b in main () at gdb.base/print-file-var-main.c:24
>  24        int v2 = get_version_2 ();
>  Value returned is $2 = 104

Now in testsuite patch form...  This is against master, where it passes
cleanly.  Walfred's patch results in:

  FAIL: gdb.base/print-file-var.exp: GDB sees same value as inferior sees while stopped in lib2

(Note: I haven't really looked deep in detail on why that is so.)

From c389985174ac2b87d14e864d1eff9b5a7e9051db Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Fri, 20 Oct 2017 16:30:46 +0100
Subject: [PATCH] Enhance gdb.base/print-file-var.exp testcase

Make sure that GDB sees the same value the inferior sees when stopped
in each library.

gdb/testsuite/ChangeLog:
2017-10-20  Pedro Alves  <palves@redhat.com>

	* gdb.base/print-file-var.exp: Check that GDB sees same value as
	inferior in each library.
---
 gdb/testsuite/gdb.base/print-file-var.exp | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/gdb/testsuite/gdb.base/print-file-var.exp b/gdb/testsuite/gdb.base/print-file-var.exp
index 223a67d..60b8e08 100644
--- a/gdb/testsuite/gdb.base/print-file-var.exp
+++ b/gdb/testsuite/gdb.base/print-file-var.exp
@@ -74,6 +74,17 @@ if ![runto_main] {
 
 set bp_location \
     [gdb_get_line_number "STOP" "${executable}.c"]
+
+# Stop in both libraries and save the value of 'this_version_id' as
+# seen from those contexts.
+gdb_breakpoint "get_version_1"
+gdb_test "continue" "Breakpoint .* get_version_1.*"
+set v1_lib1 [get_integer_valueof "this_version_id" -1]
+
+gdb_breakpoint "get_version_2"
+gdb_test "continue" "Breakpoint .* get_version_2.*"
+set v2_lib2 [get_integer_valueof "this_version_id" -1]
+
 gdb_test "break $executable.c:$bp_location" \
          "Breakpoint \[0-9\]+ at 0x\[0-9a-fA-F\]+: .*" \
          "breapoint past v1 & v2 initialization"
@@ -82,6 +93,16 @@ gdb_test "continue" \
          "Breakpoint \[0-9\]+, main \\(\\) at.*STOP.*" \
          "continue to STOP marker"
 
+# Check that the values of 'this_version_id' that we saved above when
+# stopped in both print-file-var-lib1.c:get_version_1 and
+# print-file-var-lib2.c:get_version_2 match what those functions
+# actually returned.
+
+gdb_test "print v1" " = $v1_lib1" \
+    "GDB sees same value as inferior sees while stopped in lib1"
+gdb_test "print v2" " = $v2_lib2" \
+    "GDB sees same value as inferior sees while stopped in lib2"
+
 # Now check the value of this_version_id in both print-file-var-lib1.c
 # and print-file-var-lib2.c.
 
-- 
2.5.5



  reply	other threads:[~2017-10-20 15:54 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-18  9:01 [PATCH V4] symlookup: improves symbol lookup when a file is specified Walfred Tedeschi
2017-10-19 19:07 ` Simon Marchi
2017-10-20  7:45   ` Tedeschi, Walfred
2017-10-20 14:28     ` Simon Marchi
2017-10-20 15:29       ` Pedro Alves
2017-10-20 15:54         ` Pedro Alves [this message]
2017-10-21 10:48         ` Tedeschi, Walfred
2017-10-23  9:03           ` Tedeschi, Walfred
2017-10-23 10:07             ` Pedro Alves
2017-10-25  9:39               ` Tedeschi, Walfred

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99fc3750-dc0d-45a8-d030-e37c0e1a2b77@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.com \
    --cc=simon.marchi@polymtl.ca \
    --cc=walfred.tedeschi@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox