gdb/testsuite/gdb.threads/continue-pending-status.exp

   1 # Copyright (C) 2015-2024 Free Software Foundation, Inc.
   2
   3 # This program is free software; you can redistribute it and/or modify
   4 # it under the terms of the GNU General Public License as published by
   5 # the Free Software Foundation; either version 3 of the License, or
   6 # (at your option) any later version.
   7 #
   8 # This program is distributed in the hope that it will be useful,
   9 # but WITHOUT ANY WARRANTY; without even the implied warranty of
  10 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  11 # GNU General Public License for more details.
  12 #
  13 # You should have received a copy of the GNU General Public License
  14 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
  15
  16 # This test exercises the case of stopping for a breakpoint hit of one
  17 # thread, then switching to a thread that has a status pending and
  18 # continuing.
  19
  20 require {!target_info exists gdb,nointerrupts}
  21
  22 standard_testfile
  23
  24 if [prepare_for_testing "failed to prepare" $testfile $srcfile {debug pthreads}] {
  25     return -1
  26 }
  27
  28 if ![runto_main] {
  29     return -1
  30 }
  31
  32 set break_line [gdb_get_line_number "break here"]
  33
  34 # Return current thread's number.
  35
  36 proc get_current_thread {} {
  37     global gdb_prompt
  38
  39     set thread ""
  40     set msg "get thread number"
  41     gdb_test_multiple "print /x \$_thread" $msg {
  42         -re "\\$\[0-9\]* = (0x\[0-9a-zA-Z\]+).*$gdb_prompt $" {
  43             set thread $expect_out(1,string)
  44             pass "$msg"
  45         }
  46     }
  47     return ${thread}
  48 }
  49
  50 # There are two threads in the program that are running the same tight
  51 # loop, where we place a breakpoint.  Sometimes we'll get a breakpoint
  52 # trigger for thread 2, with the breakpoint event of thread 3 pending,
  53 # other times the opposite.  The original bug that motivated this test
  54 # depended on the event thread being the highest numbered thread.  We
  55 # try the same multiple times, which should cover both threads
  56 # reporting the event.
  57
  58 set attempts 20
  59
  60 # These track whether we saw events for both threads 2 and 3.  If the
  61 # backend always returns the breakpoint hit for the same thread, then
  62 # it fails to make sure threads aren't starved, and we'll fail the
  63 # assert after the loop.
  64 set saw_thread_2 0
  65 set saw_thread_3 0
  66
  67 for {set i 0} {$i < $attempts} {incr i} {
  68     with_test_prefix "attempt $i" {
  69         gdb_test "b $srcfile:$break_line" \
  70             "Breakpoint .* at .*$srcfile, line $break_line.*" \
  71             "set break in tight loop"
  72         gdb_test "continue" \
  73             "$srcfile:$break_line.*" \
  74             "continue to tight loop"
  75
  76         # Switch to the thread that did _not_ report the event (and
  77         # thus may have a pending status).  At the time this test was
  78         # written this was necessary to make linux-nat.c short-circuit
  79         # the resume and go straight to consuming the pending event.
  80         set thread [get_current_thread]
  81         if {$thread == 2} {
  82             incr saw_thread_2
  83             set thread 3
  84         } else {
  85             incr saw_thread_3
  86             set thread 2
  87         }
  88         gdb_test "thread $thread" \
  89             "Switching to thread $thread .*" \
  90             "switch to non-event thread"
  91
  92         # Delete all breakpoints so that continuing doesn't switch
  93         # back to the event thread to do a step-over, which would mask
  94         # away the original bug, which depended on the event thread
  95         # still having TARGET_STOPPED_BY_SW_BREAKPOINT stop_reason.
  96         delete_breakpoints
  97
  98         # In the original bug, continuing would trigger an internal
  99         # error in the linux-nat.c backend.
 100
 101         set msg "continue for ctrl-c"
 102         gdb_test_multiple "continue" $msg {
 103             -re "Continuing" {
 104                 pass $msg
 105             }
 106         }
 107
 108         # Wait a bit for GDB to give the terminal to the inferior,
 109         # otherwise ctrl-c too soon can result in a "Quit".
 110         sleep 1
 111         send_gdb "\003"
 112
 113         set msg "caught interrupt"
 114         gdb_test_multiple "" $msg {
 115             -re "Thread .* received signal SIGINT.*$gdb_prompt $" {
 116                 pass $msg
 117             }
 118         }
 119     }
 120 }
 121
 122 verbose -log "saw_thread_2=$saw_thread_2"
 123 verbose -log "saw_thread_3=$saw_thread_3"
 124
 125 gdb_assert {$saw_thread_2 > 0 && $saw_thread_3 > 0} "no thread starvation"