old-cross-binutils/gdb/testsuite/gdb.threads/step-over-lands-on-breakpoint.c

69 lines
1.8 KiB
C
Raw Normal View History

Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid. Consider the case of the user doing "step" in thread 2, while thread 1 had previously stopped for a breakpoint. In order to make progress, GDB makes thread 1 step over its breakpoint first (with all other threads stopped), and once that is over, thread 2 then starts stepping (with thread 1 and all others running free, by default). If GDB didn't do that, thread 1 would just trip on the same breakpoint immediately again. This is what the prepare_to_proceed / deferred_step_ptid code is all about. However, deferred_step_ptid code resumes the target with: resume (1, GDB_SIGNAL_0); prepare_to_wait (ecs); return; Recall we were just stepping over a breakpoint when we get here. That means that _nothing_ had installed breakpoints yet! If there's another breakpoint just after the breakpoint that was just stepped, we'll miss it. The fix for that would be to use keep_going instead. However, there are more problems. What if the instruction that was just single-stepped triggers a watchpoint? Currently, GDB just happily resumes the thread, losing that too... Missed watchpoints will need yet further fixes, but we should keep those in mind. So the fix must be to let the trap fall through the regular bpstat handling, and only if no breakpoint, watchpoint, etc. claims the trap, shall we switch back to the stepped thread. Now, nowadays, we have code at the tail end of trap handling that does exactly that -- switch back to the stepped thread (switch_back_to_the_stepped_thread). So the deferred_step_ptid code is just standing in the way, and can simply be eliminated, fixing bugs in the process. Sweet. The comment about spurious "Switching to ..." made me pause, but is actually stale nowadays. That isn't needed anymore. previous_inferior_ptid used to be re-set at each (internal) event, but now it's only touched in proceed and normal stop. The two tests added by this patch fail without the fix. Tested on x86_64 Fedora 17 (also against my software single-stepping on x86 branch). gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (previous_inferior_ptid): Adjust comment. (deferred_step_ptid): Delete. (infrun_thread_ptid_changed, prepare_to_proceed) (init_wait_for_inferior): Adjust. (handle_signal_stop): Delete deferred_step_ptid handling. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c: New file. * gdb.threads/step-over-lands-on-breakpoint.exp: New file.
2014-03-20 13:26:31 +00:00
/* This testcase is part of GDB, the GNU debugger.
Copyright 2014-2016 Free Software Foundation, Inc.
Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid. Consider the case of the user doing "step" in thread 2, while thread 1 had previously stopped for a breakpoint. In order to make progress, GDB makes thread 1 step over its breakpoint first (with all other threads stopped), and once that is over, thread 2 then starts stepping (with thread 1 and all others running free, by default). If GDB didn't do that, thread 1 would just trip on the same breakpoint immediately again. This is what the prepare_to_proceed / deferred_step_ptid code is all about. However, deferred_step_ptid code resumes the target with: resume (1, GDB_SIGNAL_0); prepare_to_wait (ecs); return; Recall we were just stepping over a breakpoint when we get here. That means that _nothing_ had installed breakpoints yet! If there's another breakpoint just after the breakpoint that was just stepped, we'll miss it. The fix for that would be to use keep_going instead. However, there are more problems. What if the instruction that was just single-stepped triggers a watchpoint? Currently, GDB just happily resumes the thread, losing that too... Missed watchpoints will need yet further fixes, but we should keep those in mind. So the fix must be to let the trap fall through the regular bpstat handling, and only if no breakpoint, watchpoint, etc. claims the trap, shall we switch back to the stepped thread. Now, nowadays, we have code at the tail end of trap handling that does exactly that -- switch back to the stepped thread (switch_back_to_the_stepped_thread). So the deferred_step_ptid code is just standing in the way, and can simply be eliminated, fixing bugs in the process. Sweet. The comment about spurious "Switching to ..." made me pause, but is actually stale nowadays. That isn't needed anymore. previous_inferior_ptid used to be re-set at each (internal) event, but now it's only touched in proceed and normal stop. The two tests added by this patch fail without the fix. Tested on x86_64 Fedora 17 (also against my software single-stepping on x86 branch). gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (previous_inferior_ptid): Adjust comment. (deferred_step_ptid): Delete. (infrun_thread_ptid_changed, prepare_to_proceed) (init_wait_for_inferior): Adjust. (handle_signal_stop): Delete deferred_step_ptid handling. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c: New file. * gdb.threads/step-over-lands-on-breakpoint.exp: New file.
2014-03-20 13:26:31 +00:00
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/>. */
#include <pthread.h>
#include <unistd.h>
#include <stdlib.h>
pthread_barrier_t barrier;
pthread_t child_thread;
volatile unsigned int counter = 1;
void *
child_function (void *arg)
{
pthread_barrier_wait (&barrier);
while (counter > 0)
{
counter++;
asm (" nop"); /* set breakpoint child here */
asm (" nop"); /* set breakpoint after step-over here */
usleep (1);
}
pthread_exit (NULL);
}
int
main ()
{
int res;
long i;
Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race On a target that is both always in non-stop mode and can do displaced stepping (such as native x86_64 GNU/Linux, with "maint set target-non-stop on"), the step-over-trips-on-watchpoint.exp test sometimes fails like this: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: thread 1 set scheduler-locking off (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off step -[Switching to Thread 0x7ffff7fc0700 (LWP 11782)] -Hardware watchpoint 4: watch_me - -Old value = 0 -New value = 1 -child_function (arg=0x0) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:39 -39 other = 1; /* set thread-specific breakpoint here */ -(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step +wait_threads () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 +49 return 1; /* in wait_threads */ +(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step Note "scheduler-locking" was set off. The problem is that on such targets, the step-over of thread 2 and the "step" of thread 1 can be set to run simultaneously (since with displaced stepping the breakpoint isn't ever removed from the target), and sometimes, the "step" of thread 1 finishes first, so it'd take another resume to see the watchpoint trigger. Fix this by replacing the wait_threads function with a one-line infinite loop that doesn't call any function, so that the "step" of thread 1 never finishes. gdb/testsuite/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Change comment. * gdb.threads/step-over-trips-on-watchpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Change comment.
2015-08-06 17:22:59 +00:00
alarm (300);
Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid. Consider the case of the user doing "step" in thread 2, while thread 1 had previously stopped for a breakpoint. In order to make progress, GDB makes thread 1 step over its breakpoint first (with all other threads stopped), and once that is over, thread 2 then starts stepping (with thread 1 and all others running free, by default). If GDB didn't do that, thread 1 would just trip on the same breakpoint immediately again. This is what the prepare_to_proceed / deferred_step_ptid code is all about. However, deferred_step_ptid code resumes the target with: resume (1, GDB_SIGNAL_0); prepare_to_wait (ecs); return; Recall we were just stepping over a breakpoint when we get here. That means that _nothing_ had installed breakpoints yet! If there's another breakpoint just after the breakpoint that was just stepped, we'll miss it. The fix for that would be to use keep_going instead. However, there are more problems. What if the instruction that was just single-stepped triggers a watchpoint? Currently, GDB just happily resumes the thread, losing that too... Missed watchpoints will need yet further fixes, but we should keep those in mind. So the fix must be to let the trap fall through the regular bpstat handling, and only if no breakpoint, watchpoint, etc. claims the trap, shall we switch back to the stepped thread. Now, nowadays, we have code at the tail end of trap handling that does exactly that -- switch back to the stepped thread (switch_back_to_the_stepped_thread). So the deferred_step_ptid code is just standing in the way, and can simply be eliminated, fixing bugs in the process. Sweet. The comment about spurious "Switching to ..." made me pause, but is actually stale nowadays. That isn't needed anymore. previous_inferior_ptid used to be re-set at each (internal) event, but now it's only touched in proceed and normal stop. The two tests added by this patch fail without the fix. Tested on x86_64 Fedora 17 (also against my software single-stepping on x86 branch). gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (previous_inferior_ptid): Adjust comment. (deferred_step_ptid): Delete. (infrun_thread_ptid_changed, prepare_to_proceed) (init_wait_for_inferior): Adjust. (handle_signal_stop): Delete deferred_step_ptid handling. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c: New file. * gdb.threads/step-over-lands-on-breakpoint.exp: New file.
2014-03-20 13:26:31 +00:00
pthread_barrier_init (&barrier, NULL, 2);
res = pthread_create (&child_thread, NULL, child_function, NULL);
pthread_barrier_wait (&barrier);
Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race On a target that is both always in non-stop mode and can do displaced stepping (such as native x86_64 GNU/Linux, with "maint set target-non-stop on"), the step-over-trips-on-watchpoint.exp test sometimes fails like this: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: thread 1 set scheduler-locking off (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off step -[Switching to Thread 0x7ffff7fc0700 (LWP 11782)] -Hardware watchpoint 4: watch_me - -Old value = 0 -New value = 1 -child_function (arg=0x0) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:39 -39 other = 1; /* set thread-specific breakpoint here */ -(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step +wait_threads () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 +49 return 1; /* in wait_threads */ +(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step Note "scheduler-locking" was set off. The problem is that on such targets, the step-over of thread 2 and the "step" of thread 1 can be set to run simultaneously (since with displaced stepping the breakpoint isn't ever removed from the target), and sometimes, the "step" of thread 1 finishes first, so it'd take another resume to see the watchpoint trigger. Fix this by replacing the wait_threads function with a one-line infinite loop that doesn't call any function, so that the "step" of thread 1 never finishes. gdb/testsuite/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Change comment. * gdb.threads/step-over-trips-on-watchpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Change comment.
2015-08-06 17:22:59 +00:00
/* Use an infinite loop with no function calls so that "step" over
this line never finishes before the breakpoint in the other
thread triggers. That can happen if the step-over of thread 2 is
done with displaced stepping on a target that is always in
non-stop mode, as in that case GDB runs both threads
simultaneously. */
while (1); /* set wait-thread breakpoint here */
Fix missing breakpoint/watchpoint hits, eliminate deferred_step_ptid. Consider the case of the user doing "step" in thread 2, while thread 1 had previously stopped for a breakpoint. In order to make progress, GDB makes thread 1 step over its breakpoint first (with all other threads stopped), and once that is over, thread 2 then starts stepping (with thread 1 and all others running free, by default). If GDB didn't do that, thread 1 would just trip on the same breakpoint immediately again. This is what the prepare_to_proceed / deferred_step_ptid code is all about. However, deferred_step_ptid code resumes the target with: resume (1, GDB_SIGNAL_0); prepare_to_wait (ecs); return; Recall we were just stepping over a breakpoint when we get here. That means that _nothing_ had installed breakpoints yet! If there's another breakpoint just after the breakpoint that was just stepped, we'll miss it. The fix for that would be to use keep_going instead. However, there are more problems. What if the instruction that was just single-stepped triggers a watchpoint? Currently, GDB just happily resumes the thread, losing that too... Missed watchpoints will need yet further fixes, but we should keep those in mind. So the fix must be to let the trap fall through the regular bpstat handling, and only if no breakpoint, watchpoint, etc. claims the trap, shall we switch back to the stepped thread. Now, nowadays, we have code at the tail end of trap handling that does exactly that -- switch back to the stepped thread (switch_back_to_the_stepped_thread). So the deferred_step_ptid code is just standing in the way, and can simply be eliminated, fixing bugs in the process. Sweet. The comment about spurious "Switching to ..." made me pause, but is actually stale nowadays. That isn't needed anymore. previous_inferior_ptid used to be re-set at each (internal) event, but now it's only touched in proceed and normal stop. The two tests added by this patch fail without the fix. Tested on x86_64 Fedora 17 (also against my software single-stepping on x86 branch). gdb/ 2014-03-20 Pedro Alves <palves@redhat.com> * infrun.c (previous_inferior_ptid): Adjust comment. (deferred_step_ptid): Delete. (infrun_thread_ptid_changed, prepare_to_proceed) (init_wait_for_inferior): Adjust. (handle_signal_stop): Delete deferred_step_ptid handling. gdb/testsuite/ 2014-03-20 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c: New file. * gdb.threads/step-over-lands-on-breakpoint.exp: New file.
2014-03-20 13:26:31 +00:00
pthread_join (child_thread, NULL);
exit (EXIT_SUCCESS);
}