aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.base/consecutive-step-over.c
AgeCommit message (Collapse)AuthorFilesLines
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker1-1/+1
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files.
2019-01-01Update copyright year range in all GDB files.Joel Brobecker1-1/+1
This commit applies all changes made after running the gdb/copyright.py script. Note that one file was flagged by the script, due to an invalid copyright header (gdb/unittests/basic_string_view/element_access/char/empty.cc). As the file was copied from GCC's libstdc++-v3 testsuite, this commit leaves this file untouched for the time being; a patch to fix the header was sent to gcc-patches first. gdb/ChangeLog: Update copyright year range in all GDB files.
2018-01-02Update copyright year range in all GDB filesJoel Brobecker1-1/+1
gdb/ChangeLog: Update copyright year range in all GDB files
2017-01-01update copyright year range in GDB filesJoel Brobecker1-1/+1
This applies the second part of GDB's End of Year Procedure, which updates the copyright year range in all of GDB's files. gdb/ChangeLog: Update copyright year range in all GDB files.
2016-01-01GDB copyright headers update after running GDB's copyright.py script.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2015-01-01Update year range in copyright notice of all files owned by the GDB project.Joel Brobecker1-1/+1
gdb/ChangeLog: Update year range in copyright notice of all files.
2014-04-22Consecutive step-overs trigger internal error.Pedro Alves1-0/+28
If a thread trips on a breakpoint that needs stepping over just after finishing a step over, GDB currently fails an assertion. This is a regression caused by the "Handle multiple step-overs." patch (99619beac6252113fed212fdb9e1ab97bface423) at https://sourceware.org/ml/gdb-patches/2014-02/msg00765.html. (gdb) x /4i $pc => 0x400540 <main+4>: movl $0x0,0x2003da(%rip) # 0x600924 <i> 0x40054a <main+14>: movl $0x1,0x2003d0(%rip) # 0x600924 <i> 0x400554 <main+24>: movl $0x2,0x2003c6(%rip) # 0x600924 <i> 0x40055e <main+34>: movl $0x3,0x2003bc(%rip) # 0x600924 <i> (gdb) PASS: gdb.base/consecutive-step-over.exp: get breakpoint addresses break *0x40054a Breakpoint 2 at 0x40054a: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 23. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 1: set condition break *0x400554 Breakpoint 3 at 0x400554: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 24. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 2: set condition break *0x40055e Breakpoint 4 at 0x40055e: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 25. (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set breakpoint condition $bpnum condition (gdb) PASS: gdb.base/consecutive-step-over.exp: insn 3: set condition break 27 Breakpoint 5 at 0x400568: file ../../../src/gdb/testsuite/gdb.base/consecutive-step-over.c, line 27. (gdb) continue Continuing. ../../src/gdb/infrun.c:5200: internal-error: switch_back_to_stepped_thread: Assertion `!tp->control.trap_expected' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. FAIL: gdb.base/consecutive-step-over.exp: continue to breakpoint: break here (GDB internal error) The assertion fails, because the code is not expecting that the event thread itself might need another step over. IOW, not expecting that TP in: tp = find_thread_needs_step_over (stepping_thread != NULL, stepping_thread); could be the event thread. A small fix for this would be to clear the event thread's trap_expected earlier, before asserting. But looking deeper, although currently_stepping_or_nexting_callback's intention is finding the thread that is doing a step/next, it also returns the thread that is doing a step-over dance, with trap_expected set. If there ever was a reason for that (it was I who added currently_stepping_or_nexting_callback , but I can't recall why I put trap_expected there in the first place), the only remaining reason nowadays is to aid in implementing switch_back_to_stepped_thread's assertion that is now triggering, by piggybacking on the walk over all threads, thus avoiding a separate walk. This is quite obscure, and I think we can do even better, by merging the walks that look for the stepping thread, and the walk that looks for some thread that might need a step over. Tested on x86_64 Fedora 17, native and gdbserver, and also native on top of my "software single-step on x86_64" series. gdb/ 2014-04-22 Pedro Alves <palves@redhat.com> * infrun.c (schedlock_applies): New function, factored out from find_thread_needs_step_over. (find_thread_needs_step_over): Use it. (switch_back_to_stepped_thread): Always clear trap_expected if the step over is finished. Return early if scheduler locking applies. Look for the stepping thread and a potential step-over thread with a single loop. (currently_stepping_or_nexting_callback): Delete. 2014-04-22 Pedro Alves <palves@redhat.com> * gdb.base/consecutive-step-over.c: New file. * gdb.base/consecutive-step-over.exp: New file.
generated by cgit v1.1 at 2025-02-23 07:31:46 +0000