Re: [PATCH 2/2 ] PowerPC: fix for gdb.reverse/finish-precsave.exp and gdb.reverse/finish-reverse.exp

Bruno Larsen via Gdb-patches
2023-08-02T09:30:33Z

On 01/08/2023 00:59, Carl Love wrote:
> Bruno:
>
> On Fri, 2023-07-21 at 09:24 +0200, Bruno Larsen wrote:
>>> I think what Bruno is again asking is to have
>>> control.step_range_start
>>> set to the real start range initially, i.e. what Simon asked
>>> about. I
>>> think to do that, we would need to make significant changes to how
>>> reverse execution works to allow us to make that change. It didn't
>>> appear to be a straight forward fix to me. I may be wrong. Maybe
>>> someone sees a good way to make that work that I am missing. So it
>>> looks like this patch fixes most issues but not all of the problems
>>> with reverse-step and reverse-next. It might be good to try and
>>> fix
>>> this additional scenario in a separate patch, not sure???
>> I just tested with the newest version of the patch relating to
>> reverse
>> stepping over contiguous lines, but that didn't make a difference.
>> GCC
>> continued broken. I think the problem is that GCC doesn't have
>> contiguous ranges, it has a single range that doesn't contain the PC
>>
>> My (probably naive) thinking is to set step_range_end to the starting
>> PC
>> of the following line, and step_range_start to be the real start of
>> the
>> current line at the moment the command is parsed. This sounds like
>> it
>> would solve the GCC problem, but I assume I'm missing something.
>> Unfortunately, I don't have the time to test this theory myself, but
>> I'll happily test any patches you submit :). If you want to repeat
>> my
>> test, I want the behavior of gdb.reverse/finish-reverse-next from gcc
>> to
>> match clang's (on x86 machines), that is, if you reverse finish from
>> function1, a single "rn" command would land you on the b=5 line.
> So, I took the example of the error from your previous patch where you
> demonstrated the scenario where you have stopped at the call to the
> function, then do the reverse-next which stops at the beginning of the
> same line and put it into a new test case for discussion and for
> debugging the issue. Nice to have a simple example of the issue. The
> new test is bruno_7_20_2023.exp. So, in this test, when we are stopped
> at the call, as you showed on Intel
>
> (gdb) maint info line-table
>> (snip)
>> 15 81 0x0000000000401185 0x0000000000401185 Y
>> 16 83 0x000000000040118c 0x000000000040118c Y
>> 17 86 0x000000000040119b 0x000000000040119b Y
>> (gdb) disas /s
>> Dump of assembler code for function main:
>> (snip)
>> 83 function1 (a, b); // CALL VIA LEP
>> 0x000000000040118c <+37>: mov -0x10(%rbp),%edx
>> 0x000000000040118f <+40>: mov -0xc(%rbp),%eax
>> 0x0000000000401192 <+43>: mov %edx,%esi
>> 0x0000000000401194 <+45>: mov %eax,%edi
>> => 0x0000000000401196 <+47>: call 0x40112c <function1>
>>
>> We can see that we have stopped at the right instruction, but it
>> isn't
>> mapped to any line number directly. If we reverse-next from there:
> the tp->control.step_range_start is set to 0x40118c in function
> prepare_one_step() in gdb/infcmd.c. The PC in your case is at
> 0x401196. Of course both of the addresses are in the same line. We
> are executing backwards so we need step_range_start to be set to a
> value in the previous line. In general, we have no idea what the
> previous line was as we may have arrived on this line via a jump or
> branch in theory. Also, note, when setting the range we need to have
> the PC in the range or GDB will give us an assert error.
>
> So really the issue is that we want the step_range_start to be in the
> line where we came from. So, if we see the line number for PC and
> step_range_start are the same, we can set step_range_start to one less
> then the address of the beginning of the current line when we parse the
> instruction and setup the stepping range. The goal is to have GDB stop
> in the previous line and not at the beginning of the line and thus
> match the behavior of gdb on clang.
>
> I implemented the check and adjustment for step_range_start as just
> described and tested it with your example, bruno_7_20_2023.exp and it
> does seem to work as desired.
>
> The existing testcases expect to have to do two reverse step/next
> instructions to reach the previous line. So, we need to fix the
> existing tests gdb.reverse/finish-reverse-next.exp and gdb.mi/mi-
> reverse.exp to remove the extra reverse step/next command.
>
> Anyway, I put the gdb code fix, the bruno_7_20_2023.exp and test fixes
> into the patch below for discussion purposes. If everyone is happy
> with the gdb change and test changes (we can drop the Bruno test) I can
> merge these changes into the patch. Hopefully keeping these changes in
> a separate patch for the moment will make it easier to see what is
> being changed.

Hi Carl!

Thanks for the thorough explanation and test. You did understood what I
meant perfectly :)

This is a little besides the point, but I don't see any other patches
that touch this area and haven't been committed yet. Am I missing
something obvious?

Regardless, I feel like this one change can propagate enough that it
should be its own commit anyway.

>
> If you were to apply the following patch on top of the currently
> proposed patch, does gdb then execute as you expect on your system? I
> have tested the change on IBM Power 10. It would be good to make sure
> it works on your X86 system as well. I also ran the full gdb
> regression tests on Power 10 with no additional regression failures.
> Thanks for looking at the patch, proposed fix and the additional
> testing.

The patch didn't apply on current master, but I added the changes
manually and tested it. It does fix the issue, and adds no regressions.

I feel like it could be worth sending an official version this patch as
a new thread, instead of a reply to this one, to get people who might
not be interested in reverse debugging but may have thoughts on this
patch, but maybe wait a bit to see if someone in here says anything :)

--
Cheers,
Bruno

>
> Carl
> ---------------------------------------------------------------
> [PATCH 2/2] finish-reverse-next new test case from bruno.
>
> GDB fix for Bruno test, updated other tests for the gdb fix.
> ---
> gdb/infcmd.c | 9 ++
> gdb/testsuite/gdb.mi/mi-reverse.exp | 6 +-
> gdb/testsuite/gdb.reverse/bruno_7_20_2023.exp | 85 +++++++++++++++++++
> .../gdb.reverse/finish-reverse-next.exp | 44 +++++++---
> 4 files changed, 133 insertions(+), 11 deletions(-)
> create mode 100644 gdb/testsuite/gdb.reverse/bruno_7_20_2023.exp
>
> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
> index b8134665f3f..c09b3edad3d 100644
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -981,6 +981,15 @@ prepare_one_step (thread_info *tp, struct step_command_fsm *sm)
> find_pc_line_pc_range (pc,
> &tp->control.step_range_start,
> &tp->control.step_range_end);
> + symtab_and_line sal = find_pc_line (pc, 0);
> + symtab_and_line sal_start
> + = find_pc_line (tp->control.step_range_start, 0);
> +
> + if (sal.line == sal_start.line)
> + /* The step_range_start address is in the same line. We want to
> + stop in the previous line so move step_range_start one
> + instruction earlier. */
> + tp->control.step_range_start--;
>
> /* There's a problem in gcc (PR gcc/98780) that causes missing line
> table entries, which results in a too large stepping range.
> diff --git a/gdb/testsuite/gdb.mi/mi-reverse.exp b/gdb/testsuite/gdb.mi/mi-reverse.exp
> index baa53a495d7..997309cfb71 100644
> --- a/gdb/testsuite/gdb.mi/mi-reverse.exp
> +++ b/gdb/testsuite/gdb.mi/mi-reverse.exp
> @@ -99,8 +99,12 @@ proc test_controlled_execution_reverse {} {
> # It takes two steps to get back to the previous line,
> # as the first step moves us to the start of the current line,
> # and the one after that moves back to the previous line.
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
>
> - mi_execute_to "exec-next --reverse 2" \
> + mi_execute_to "exec-next --reverse" \
> "end-stepping-range" "main" "" \
> "basics.c" $line_main_hello "" \
> "reverse next to get over the call to do_nothing"
> diff --git a/gdb/testsuite/gdb.reverse/bruno_7_20_2023.exp b/gdb/testsuite/gdb.reverse/bruno_7_20_2023.exp
> new file mode 100644
> index 00000000000..0f19a959043
> --- /dev/null
> +++ b/gdb/testsuite/gdb.reverse/bruno_7_20_2023.exp
> @@ -0,0 +1,85 @@
> +# Copyright 2008-2023 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program. If not, see <http://www.gnu.org/licenses/>. */
> +
> +# This file is part of the GDB testsuite. It tests reverse stepping.
> +# Lots of code borrowed from "step-test.exp".
> +
> +# The reverse finish command should return from a function and stop on
> +# the first instruction of the source line where the function call is made.
> +# Specifically, the behavior should match doing a reverse next from the
> +# first instruction in the function. GDB should only take one reverse step
> +# or next statement to reach the previous source code line.
> +
> +# This testcase verifies the reverse-finish command stops at the first
> +# instruction in the source code line where the function was called. There
> +# are two scenarios that must be checked:
> +# 1) gdb is at the entry point instruction for the function
> +# 2) gdb is in the body of the function.
> +
> +# This test verifies the fix for gdb bugzilla:
> +# https://sourceware.org/bugzilla/show_bug.cgi?id=29927
> +
> +# PowerPC supports two entry points to a function. The normal entry point
> +# is called the local entry point (LEP). The alternate entry point is called
> +# the global entry point (GEP). A function call via a function pointer
> +# will entry via the GEP. A normal function call will enter via the LEP.
> +#
> +# This test has been expanded to include tests to verify the reverse-finish
> +# command works properly if the function is called via the GEP. The original
> +# test only verified the reverse-finish command for a normal call that used
> +# the LEP.
> +
> +if ![supports_reverse] {
> + return
> +}
> +
> +standard_testfile finish-reverse-next.c
> +
> +if { [prepare_for_testing "failed to prepare" $testfile $srcfile] } {
> + return -1
> +}
> +
> +runto_main
> +set target_remote [gdb_is_target_remote]
> +
> +if [supports_process_record] {
> + # Activate process record/replay.
> + gdb_test_no_output "record" "turn on process record for test1"
> +}
> +
> +
> +# until 83
> +# Set breakpoint at call to function1 in main.
> +set bp_LEP_test [gdb_get_line_number "CALL VIA LEP" $srcfile]
> +gdb_breakpoint $srcfile:$bp_LEP_test temporary
> +
> +# Continue to break point at function1 call in main.
> +gdb_continue_to_breakpoint \
> + "stopped at function1 entry point instruction to stepi into function" \
> + ".*$srcfile:$bp_LEP_test\r\n.*"
> +
> +gdb_test "next" ".*a = 10;.*" \
> + "next from function body function1 LEP to a = 10;"
> +
> +gdb_test "reverse-step" ".*70.*}.*" \
> + "reverse step from a = 10, stops at last inst in function1 call"
> +
> +gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \
> + "reverse-finish should stop at last inst in line for function1"
> +
> +gdb_test "reverse-next" ".*b = 5;.*" \
> + "reverse-finish should stop at b = 5, not first inst in line for function1"
> +
> +
> diff --git a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp
> index 1f53b649a7d..921d0051233 100644
> --- a/gdb/testsuite/gdb.reverse/finish-reverse-next.exp
> +++ b/gdb/testsuite/gdb.reverse/finish-reverse-next.exp
> @@ -80,10 +80,15 @@ repeat_cmd_until "stepi" "CALL VIA LEP" "{" "stepi into function1 call" "100"
> # instruction should then stop at the first instruction in the same source
> # code line. Another revers-next instruction stops at the previous source
> # code line.
> +
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
> gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \
> "reverse-finish function1 LEP call from LEP "
> -gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP" \
> - "reverse next 1 LEP entry point function call from LEP"
> +##gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP" \
> +## "reverse next 1 LEP entry point function call from LEP"
> gdb_test "reverse-next" ".*b = 5;.*" "reverse next 2, at b = 5, call from LEP"
>
>
> @@ -113,10 +118,14 @@ gdb_test "step" ".*int ret = 0;.*" "step test 1"
> # instruction should then stop at the first instruction in the same source
> # code line. Another revers-next instruction stops at the previous source
> # code line.
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
> gdb_test "reverse-finish" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \
> "reverse-finish function1 LEP call from function body"
> -gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \
> - "reverse next 1 LEP from function body"
> +## gdb_test "reverse-next" ".*function1 \\(a, b\\); // CALL VIA LEP.*" \
> +## "reverse next 1 LEP from function body"
> gdb_test "reverse-next" ".*b = 5;.*" \
> "reverse next 2 at b = 5, from function body"
>
> @@ -148,10 +157,15 @@ repeat_cmd_until "stepi" "CALL VIA GEP" "{" "stepi into funp call"
> # instruction should then stop at the first instruction in the same source
> # code line. Another revers-next instruction stops at the previous source
> # code line.
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
> +
> gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \
> "function1 GEP call call from GEP"
> -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> - "reverse next 1 GEP entry point function call from GEP"
> +## gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> +## "reverse next 1 GEP entry point function call from GEP"
> gdb_test "reverse-next" ".*b = 50;.*" "reverse next 2 at b = 50, call from GEP"
>
> gdb_test "reverse-continue" ".*" "setup for test 4"
> @@ -184,10 +198,15 @@ gdb_test "stepi" "{" "stepi to between GEP and LEP"
> # instruction should then stop at the first instruction in the same source
> # code line. Another revers-next instruction stops at the previous source
> # code line.
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
> +
> gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \
> "function1 GEP call call from GEP again"
> -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> - "reverse next 1 GEP entry point function call from GEP again"
> +##gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> +## "reverse next 1 GEP entry point function call from GEP again"
> gdb_test "reverse-next" ".*b = 50;.*" \
> "reverse next 2 at b = 50, call from GEP again"
>
> @@ -216,9 +235,14 @@ gdb_test "step" ".*int ret = 0;.*" "step test 2"
> # instruction should then stop at the first instruction in the same source
> # code line. Another revers-next instruction stops at the previous source
> # code line.
> +## I BELIEVE Bruno is arguing this part of the test is wrong. When we are
> +## stopped at the call, which is the last instruction in the line, the
> +## reverse next should take us directly to the previous line, not stop at
> +## the first instruction in the same line.
> +
> gdb_test "reverse-finish" ".*funp \\(a, b\\);.*" \
> "reverse-finish function1 GEP call, from function body "
> -gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> - "reverse next 1 GEP call from function body"
> +## gdb_test "reverse-next" ".*funp \\(a, b\\);.*" \
> +## "reverse next 1 GEP call from function body"
> gdb_test "reverse-next" ".*b = 50;.*" \
> "reverse next 2 at b = 50 from function body"