public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug gdb/29962] New: FAIL: gdb.reverse/step-reverse.exp: reverse step into fn call Date: Wed, 04 Jan 2023 10:09:17 +0000 [thread overview] Message-ID: <bug-29962-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=29962 Bug ID: 29962 Summary: FAIL: gdb.reverse/step-reverse.exp: reverse step into fn call Product: gdb Version: unknown Status: NEW Severity: normal Priority: P2 Component: gdb Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- [ Likewise for gdb.reverse/step-precsave.exp, which uses the same source file. ] On ubuntu 20.04.5 x86_64 (using gcc 9.4.0), I run into: ... (gdb) PASS: gdb.reverse/step-reverse.exp: simple reverse stepi step^M 78 a[5] = a[3] - a[4]; /* FINISH TEST */^M (gdb) FAIL: gdb.reverse/step-reverse.exp: reverse step into fn call step^M ... The basic problem here is that the forward execution goes like: ... $ ./build/gdb/gdb -q -batch ./build/gdb/testsuite/outputs/gdb.reverse/step-reverse/step-reverse -ex "b 78" -ex run -ex "set trace-commands on" -ex stepi -ex "stepi" -ex "stepi" -ex "stepi" -ex "stepi" Breakpoint 1 at 0x123b: file /home/vries/gdb/src/gdb/testsuite/gdb.reverse/step-reverse.c, line 78. Breakpoint 1, main () at /home/vries/gdb/src/gdb/testsuite/gdb.reverse/step-reverse.c:78 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 0x0000555555555243 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 79 callee(); /* STEPI TEST */ $ ... because we have: ... INDEX LINE ADDRESS IS-STMT PROLOGUE-END 26 75 0x0000555555555231 Y 27 78 0x000055555555523b Y 28 78 0x000055555555523e Y 29 78 0x0000555555555241 Y 30 78 0x0000555555555245 Y 31 79 0x0000555555555248 Y ... and when doing the backward execution, we stop at 0x0000555555555245 rather stepi-ing to 0x000055555555523b as is the intention. This simple test-case patch fixes it: ... diff --git a/gdb/testsuite/gdb.reverse/step-reverse.exp b/gdb/testsuite/gdb.reverse/step-reverse.exp index 27e4b175274..8ed4f6d0269 100644 --- a/gdb/testsuite/gdb.reverse/step-reverse.exp +++ b/gdb/testsuite/gdb.reverse/step-reverse.exp @@ -72,6 +72,8 @@ gdb_test_multiple "finish" "$test_message" { } } +set pc_finish_test [get_valueof /x {$pc} ""] + # stepi over flat code (no calls) set test_message "simple stepi" @@ -216,7 +218,13 @@ gdb_test_multiple "stepi" "$test_message" { exp_continue } -re "$stepi_location.* FINISH TEST.*$gdb_prompt $" { - pass "$test_message" + set pc [get_valueof /x {$pc} ""] + if { $pc != $pc_finish_test } { + send_gdb "stepi\n" + exp_continue + } else { + pass "$test_message" + } } -re "STEP INTO THIS CALL.*$gdb_prompt $" { fail "$test_message (too far)" ... (though it introduces a duplicate for the get_valueof). OTOH, this can be fixed by: ... diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 851852404eb..0e6ee8fe04d 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -20205,11 +20205,6 @@ dwarf_record_line_p (struct dwarf2_cu *cu, return 1; if (line != last_line) return 1; - /* Same line for the same file that we've seen already. - As a last check, for pr 17276, only record the line if the line - has never had a non-zero discriminator. */ - if (!line_has_non_zero_discriminator) - return 1; return 0; } ... which gets us: ... 25 75 0x0000555555555231 Y 26 78 0x000055555555523b Y 27 79 0x0000555555555248 Y ... and: ... Breakpoint 1, main () at step-reverse.c:78 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 0x000055555555523e 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 0x0000555555555241 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 0x0000555555555243 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 0x0000555555555245 78 a[5] = a[3] - a[4]; /* FINISH TEST */ +stepi 79 callee(); /* STEPI TEST */ ... So in that sense, it's similar to PR25911. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2023-01-04 10:09 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-04 10:09 vries at gcc dot gnu.org [this message] 2023-01-04 13:30 ` [Bug gdb/29962] " vries at gcc dot gnu.org 2023-01-04 17:18 ` vries at gcc dot gnu.org 2023-01-11 9:39 ` vries at gcc dot gnu.org 2023-01-11 10:03 ` vries at gcc dot gnu.org 2023-01-11 10:06 ` vries at gcc dot gnu.org 2023-01-11 10:08 ` vries at gcc dot gnu.org 2023-01-12 11:55 ` vries at gcc dot gnu.org 2023-01-12 16:30 ` vries at gcc dot gnu.org
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=bug-29962-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /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: linkBe 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).