From: Carl Love <cel@us.ibm.com>
To: Bruno Larsen <blarsen@redhat.com>,
Tom de Vries <tdevries@suse.de>,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
gdb-patches@sourceware.org
Cc: cel@us.ibm.com
Subject: RE: [PATCH 2/2 version 2] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp
Date: Fri, 20 Jan 2023 12:04:53 -0800 [thread overview]
Message-ID: <71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com> (raw)
In-Reply-To: <d956a591cc7b7845495ec70023ea993e64198b73.camel@us.ibm.com>
On Thu, 2023-01-19 at 15:57 -0800, Carl Love wrote:
> Bruno, Tom:
>
>
> On Thu, 2023-01-19 at 08:56 -0800, Carl Love wrote:
>
<snip>
>
> Without the patch, when you were in the main program at "answer += 1"
> and did a reverse-next, gdb would go back thru the call to function
> bar
> and thru the call to function foo stopping in main. That doesn't
> seem
> right to me as you have stepped back thru function foo and bar.
>
> With the patch the reverse-next only step back thru function bar and
> stops in function foo at the call to bar, i.e. doesn't continue to
> step
> back thru function bar.
>
> The following is the tailcall source code with comments showing where
> the reverse-step and reverse-next stop with and without the X86 patch
> applied. Hopefully the code below is a little easier to follow.
> Initially, the reverse-step and reverse-next tests are executed from
> the line "answer += 1;" in function main.
>
>
> static __attribute__ ((noinline)) int
> bar (void)
> {
> return 42;
> } <- reverse-step stops here (with no patch
> and with X86 patch)
>
> static __attribute__ ((noinline)) int
> foo (void)
> {
> return bar (); <- reverse-next stops here (patch X86 applied)
> }
>
> int
> main (void)
> {
> int answer;
>
> answer = foo (); <- reverse-next tops here (no patch applied,
> stepped
> back thru both the bar and foo functions)
> answer += 1; <- GDB is here, now issue the reverse-step
> and reverse-next commands
>
> return answer;
> }
>
> As a result of the change in the reverse-next instruction, the
> expected
> test results for the tailcall test need to be updated to reflect the
> fact that gdb now stops in function foo not main.
>
> --- a/gdb/testsuite/gdb.btrace/tailcall.exp
> +++ b/gdb/testsuite/gdb.btrace/tailcall.exp
> @@ -102,9 +102,9 @@ gdb_test "reverse-step" "\[^\r\n\]*main \\(\\) at
> tailcall.c
> :37\r\n.*" \
> "reverse-step.2"
> gdb_test "next" "\[^\r\n\]*38.*" \
> "next.1"
> -gdb_test "reverse-next" "\[^\r\n\]*main \\(\\) at
> tailcall.c:37\r\n.*" \
> +gdb_test "reverse-next" "\[^\r\n\]*foo \\(\\) at
> tailcall.c:29\r\n.*" \
> "reverse-next.1"
> -gdb_test "step" "\[^\r\n\]*foo \\(\\) at tailcall.c:29\r\n.*" \
> +gdb_test "step" "\[^\r\n\]*bar \\(\\) at tailcall.c:24\r\n.*" \
> "step.1"
> gdb_test "finish" "\[^\r\n\]*main \\(\\) at tailcall.c:38\r\n.*" \
> "finish.2"
>
> With this change, the tailcall.exp test now passes on my X86 laptop.
> The PowerPC do not change since the test is not supported on PowerPC.
>
> I will post an updated version of the X86 patch with the fixes to the
> tailcall test. It will be version 3. There are no changes to the
> PowerPC patch.
>
> The gdb.btrace/rn-dl-bind.exp test passes with and without my
> patches.
> I still can not get this test to fail on my system.
I have been thinking about this and have decided the above change is
not what we should do. Basically if we forward step at answer = foo();
we stop at answer += 1;. Which is the expected behavior for next. So,
is we are at answer += 1; and do a reverse step it should take us to
answer = foo(). It would be the opposite of the forward next.
I think I have identified the single line in the function call
set_step_info() which caused the regression in gdb.btrace/tailcall.exp.
I have so far run a few experiments and it looks like not doing the
statement:
tp->control.step_stack_frame_id = get_stack_frame_id (frame);
eliminates the regression in tailcall.exp.
So far. I need to do some more testing but it looks like there is a
couple of regressions on my X86 laptop. It looks like the expected
behavior in both of these tests is for the reverse step over a function
stops at a function call within the function not stepping all the way
back to the call of the function. Basically, the expected behavior of
these reverse tests is not consistent across tests.
I am not seeing any PowerPC regression failures with the above change.
My IBM x86 machine tests are still running.
Anyway, just wanted to give people a heads up that I am pursuing
another fix and that I now think the above fix is not the best
direction to go.
Carl
next prev parent reply other threads:[~2023-01-20 20:04 UTC|newest]
Thread overview: 105+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f594ec0070a6c585e83a6d6c8b29481a86778c0f.camel@us.ibm.com>
[not found] ` <bc6bb459f153c0c5850d4a3e5d80bbf957ec36cc.camel@de.ibm.com>
[not found] ` <8bce850fa1e03e798506dc170d9b57f52034a18a.camel@us.ibm.com>
[not found] ` <cb5875db4e1ac60475877c685e5f172770314523.camel@de.ibm.com>
[not found] ` <adeeeae47c4ca79b32d79aea632ff8b2a24dd93d.camel@us.ibm.com>
[not found] ` <86c5e9c47945894f21b1d8bf6089c730a9f0e1a5.camel@de.ibm.com>
[not found] ` <b1d7ea600d6bb7af487968d938566fae9d5e1745.camel@us.ibm.com>
[not found] ` <5f9047b9582403561d7cce998cab9184167366a1.camel@de.ibm.com>
[not found] ` <e7c8093c350ad475277154014a4f0bb9b472b7af.camel@us.ibm.com>
[not found] ` <f8d6379aff7af076d9edcee7d2981d052b2161ee.camel@de.ibm.com>
[not found] ` <5b50668cbe882c57b8c0e9dcf5be0a253713c4c6.camel@us.ibm.com>
[not found] ` <51c4bfc82ac72e475e10577dc60e4d75fa48767e.camel@de.ibm.com>
[not found] ` <3ea97a8aa9cccb39299adde682f92055d1986ab3.camel@us.ibm.com>
[not found] ` <f5ea8da12631f2496ba0e2263e65a0adc7ac56ca.camel@de.ibm.com>
[not found] ` <53878e37c6e57de1d04d9c9960c5d0a74324ee6e.camel@us.ibm.com>
[not found] ` <a5300b64533fdc753c1d50fa0e6efc21b5457547.camel@de.ibm.com>
[not found] ` <50474aa92ba82eff05cdc8f49001eae56be29670.camel@us.ibm.com>
[not found] ` <f3ef4486c4ba051024602928acdfe5ddf6942b82.camel@de.ibm.com>
[not found] ` <dae6c9790b23a90d5f1494f5b6798346444f257e.camel@us.ibm.com>
[not found] ` <89331c26795e3f7743e1e068dce43b3c2dd53008.camel@us.ibm.com>
[not found] ` <c10a008e441666e4edb0916842d8eefe83f5b2f9.camel@de.ibm.com>
[not found] ` <071f24ecf9b3a2bbbe8fee7db77492eb55c5f3ff.camel@us.ibm.com>
[not found] ` <1d9b21914354bef6a290ac30673741e722e11757.camel@de.ibm.com>
2023-01-11 18:27 ` [PATCH 0/2] " Carl Love
2023-01-11 18:27 ` [PATCH 1/2] " Carl Love
2023-01-12 16:56 ` Tom de Vries
2023-01-12 18:54 ` Carl Love
2023-01-13 13:33 ` Bruno Larsen
2023-01-13 16:43 ` Carl Love
2023-01-13 17:04 ` Bruno Larsen
2023-01-13 19:10 ` Carl Love
2023-01-14 18:08 ` Carl Love
2023-01-16 12:31 ` Bruno Larsen
2023-01-16 16:37 ` [PATCH 0/2 version 2] " Carl Love
2023-01-16 16:37 ` [PATCH 1/2 " Carl Love
2023-01-17 12:35 ` Bruno Larsen
2023-01-20 0:03 ` [PATCH 1/2 version 3] " Carl Love
2023-01-23 19:17 ` Pedro Alves
2023-01-23 21:13 ` Carl Love
2023-01-24 14:08 ` Pedro Alves
2023-01-24 14:23 ` Bruno Larsen
2023-01-24 15:06 ` Pedro Alves
2023-01-24 16:04 ` Bruno Larsen
2023-01-24 19:12 ` Pedro Alves
2023-01-25 9:49 ` Bruno Larsen
2023-01-25 14:11 ` Ulrich Weigand
2023-01-25 16:42 ` Pedro Alves
2023-01-25 17:13 ` Ulrich Weigand
2023-01-25 17:24 ` Pedro Alves
2023-01-25 19:38 ` Carl Love
2023-01-24 15:51 ` Carl Love
2023-01-24 18:37 ` Pedro Alves
2023-01-24 18:25 ` Carl Love
2023-01-24 19:21 ` Pedro Alves
2023-01-24 19:26 ` Pedro Alves
2023-01-31 0:17 ` Reverse-next bug test case Carl Love
2023-02-01 14:37 ` Pedro Alves
2023-02-01 18:40 ` Carl Love
2023-01-24 15:53 ` [PATCH 1/2 version 3] fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp Tom de Vries
2023-01-24 18:48 ` Pedro Alves
2023-01-16 16:37 ` [PATCH 2/2 version 2] " Carl Love
2023-01-17 14:29 ` Bruno Larsen
2023-01-17 16:36 ` Carl Love
2023-01-17 16:55 ` Tom de Vries
2023-01-17 17:03 ` Carl Love
2023-01-17 17:14 ` Tom de Vries
2023-01-17 19:31 ` Carl Love
2023-01-18 10:55 ` Tom de Vries
2023-01-18 16:16 ` Carl Love
2023-01-18 22:26 ` Carl Love
2023-01-19 8:04 ` Bruno Larsen
2023-01-19 16:56 ` Carl Love
2023-01-19 23:57 ` Carl Love
2023-01-20 20:04 ` Carl Love [this message]
2023-01-23 16:42 ` [PATCH 1/2 version 3] " Carl Love
2023-01-23 16:42 ` [PATCH 2/2 " Carl Love
2023-02-10 20:55 ` [PATCH ] PowerPC: " Carl Love
2023-02-17 12:24 ` Ulrich Weigand
2023-02-20 16:34 ` Carl Love
2023-02-20 16:48 ` Bruno Larsen
2023-02-20 20:24 ` Carl Love
2023-02-27 16:09 ` [PING] " Carl Love
2023-02-28 13:39 ` Bruno Larsen
2023-02-28 16:19 ` Carl Love
2023-03-01 13:43 ` Tom de Vries
2023-03-01 16:26 ` Carl Love
2023-03-01 14:03 ` Tom de Vries
2023-03-01 16:43 ` Carl Love
2023-03-01 14:34 ` Tom de Vries
2023-03-01 20:39 ` Carl Love
2023-03-01 20:59 ` [PATCH 0/2 " Carl Love
2023-03-01 20:59 ` [PATCH 1/2] " Carl Love
2023-03-03 11:56 ` Bruno Larsen
2023-03-08 16:19 ` [PING] " Carl Love
2023-03-09 16:09 ` Carl Love
2023-03-09 19:03 ` Tom Tromey
2023-03-09 21:42 ` Carl Love
2023-03-09 21:54 ` [PATCH 1/2 ver 2] " Carl Love
2023-03-10 3:53 ` Tom Tromey
2023-03-01 20:59 ` [PATCH 2/2 ] " Carl Love
2023-03-08 16:19 ` [PING] " Carl Love
2023-03-09 16:09 ` Carl Love
2023-03-13 14:16 ` Ulrich Weigand
2023-03-13 17:31 ` Carl Love
2023-03-13 17:38 ` [PATCH 2/2 ver2] " Carl Love
2023-03-17 17:19 ` Ulrich Weigand
2023-03-17 23:05 ` Tom de Vries
2023-03-20 15:04 ` Carl Love
2023-03-20 23:21 ` Carl Love
2023-03-21 3:17 ` Carl Love
2023-03-21 6:52 ` Ulrich Weigand
2023-03-24 17:23 ` [PATCH 2/2 ] " Simon Marchi
2023-03-24 22:16 ` Carl Love
2023-03-25 12:39 ` Simon Marchi
2023-03-27 23:59 ` Carl Love
2023-03-28 1:19 ` Simon Marchi
2023-03-28 15:17 ` Carl Love
2023-03-28 15:38 ` Simon Marchi
2023-07-20 12:01 ` Bruno Larsen
2023-07-20 14:45 ` Carl Love
2023-07-21 7:24 ` Bruno Larsen
2023-07-31 22:59 ` Carl Love
2023-08-02 9:29 ` Bruno Larsen
2023-08-02 15:11 ` Carl Love
2023-01-13 15:42 ` [PATCH 1/2] " Bruno Larsen
2023-01-11 18:27 ` [PATCH 2/2] " Carl Love
2023-01-13 15:55 ` Bruno Larsen
2023-01-14 18:08 ` Carl Love
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=71aa635593df0677811afb85409aa190bcfa4f6a.camel@us.ibm.com \
--to=cel@us.ibm.com \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=blarsen@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tdevries@suse.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).