binutils-gdb/gdb/testsuite/gdb.threads/signal-command-handle-nopas...

83 lines
2.6 KiB
Plaintext
Raw Normal View History

# Copyright (C) 2014-2019 Free Software Foundation, Inc.
Always pass signals to the right thread Currently, GDB can pass a signal to the wrong thread in several different but related scenarios. E.g., if thread 1 stops for signal SIGFOO, the user switches to thread 2, and then issues "continue", SIGFOO is actually delivered to thread 2, not thread 1. This obviously messes up programs that use pthread_kill to send signals to specific threads. This has been a known issue for a long while. Back in 2008 when I made stop_signal be per-thread (2020b7ab), I kept the behavior -- see code in 'proceed' being removed -- wanting to come back to it later. The time has finally come now. The patch fixes this -- on resumption, intercepted signals are always delivered to the thread that had intercepted them. Another example: if thread 1 stops for a breakpoint, the user switches to thread 2, and then issues "signal SIGFOO", SIGFOO is actually delivered to thread 1, not thread 2, because 'proceed' first switches to thread 1 to step over its breakpoint... If the user deletes the breakpoint before issuing "signal FOO", then the signal is delivered to thread 2 (the current thread). "signal SIGFOO" can be used for two things: inject a signal in the program while the program/thread had stopped for none, bypassing "handle nopass"; or changing/suppressing a signal the program had stopped for. These scenarios are really two faces of the same coin, and GDB can't really guess what the user is trying to do. GDB might have intercepted signals in more than one thread even (see the new signal-command-multiple-signals-pending.exp test). At least in the inject case, it's obviously clear to me that the user means to deliver the signal to the currently selected thread, so best is to make the command's behavior consistent and easy to explain. Then, if the user is trying to suppress/change a signal the program had stopped for instead of injecting a new signal, but, the user had changed threads meanwhile, then she will be surprised that with: (gdb) continue Thread 1 stopped for signal SIGFOO. (gdb) thread 2 (gdb) signal SIGBAR ... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2 (with scheduler-locking off, which is the default, because then "signal" or any other resumption command resumes all threads). So the patch makes GDB detect that, and ask for confirmation: (gdb) thread 1 [Switching to thread 1 (Thread 10979)] (gdb) signal SIGUSR2 Note: Thread 3 previously stopped with signal SIGUSR2, User defined signal 2. Thread 2 previously stopped with signal SIGUSR1, User defined signal 1. Continuing thread 1 (the current thread) with specified signal will still deliver the signals noted above to their respective threads. Continue anyway? (y or n) All these scenarios are covered by the new tests. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-07-25 Pedro Alves <palves@redhat.com> * NEWS: Mention signal passing and "signal" command changes. * gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend comment. * breakpoint.c (until_break_command): Adjust clear_proceed_status call. * infcall.c (run_inferior_call): Adjust clear_proceed_status call. * infcmd.c (proceed_thread_callback, continue_1, step_once) (jump_command): Adjust clear_proceed_status call. (signal_command): Warn if other thread that are resumed have signals that will be delivered. Adjust clear_proceed_status call. (until_next_command, finish_command) (proceed_after_attach_callback, attach_command_post_wait) (attach_command): Adjust clear_proceed_status call. * infrun.c (proceed_after_vfork_done): Likewise. (proceed_after_attach_callback): Adjust comment. (clear_proceed_status_thread): Clear stop_signal if not in pass state. (clear_proceed_status_callback): Delete. (clear_proceed_status): New 'step' parameter. Only clear the proceed status of threads the command being prepared is about to resume. (proceed): If passed in an explicit signal, override stop_signal with it. Don't pass the last stop signal to the thread we're resuming. (init_wait_for_inferior): Adjust clear_proceed_status call. (switch_back_to_stepped_thread): Clear the signal if it should not be passed. * infrun.h (clear_proceed_status): New 'step' parameter. (user_visible_resume_ptid): Add comment. * linux-nat.c (linux_nat_resume_callback): Don't check whether the signal is in pass state. * remote.c (append_pending_thread_resumptions): Likewise. * mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call. gdb/doc/ 2014-07-25 Pedro Alves <palves@redhat.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Signaling) <signal command>: Explain what happens with multi-threaded programs. gdb/testsuite/ 2014-07-25 Pedro Alves <palves@redhat.com> * gdb.threads/signal-command-handle-nopass.c: New file. * gdb.threads/signal-command-handle-nopass.exp: New file. * gdb.threads/signal-command-multiple-signals-pending.c: New file. * gdb.threads/signal-command-multiple-signals-pending.exp: New file. * gdb.threads/signal-delivered-right-thread.c: New file. * gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 17:57:31 +02: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/>. */
# Test that an explicit "signal FOO" delivers FOO even if "handle" for
# that same signal is set to "nopass". Also make sure the signal is
# delivered to the right thread, even if GDB has to step over a
# breakpoint in some other thread first.
if [target_info exists gdb,nosignals] {
verbose "Skipping ${testfile}.exp because of nosignals."
return -1
}
standard_testfile
if {[gdb_compile_pthreads "${srcdir}/${subdir}/${srcfile}" "${binfile}" \
executable { debug }] != "" } {
return -1
}
# Run the test proper. STEP_OVER indicates whether we leave in place
# a breakpoint that needs to be stepped over when we explicitly
# request a signal be delivered with the "signal" command.
proc test { step_over } {
global srcfile binfile
with_test_prefix "step-over $step_over" {
clean_restart ${binfile}
if ![runto_main] then {
Fix test names starting with uppercase output by basic functions The following patch is based on the previous patch i sent and handles cases of test names that start with an uppercase letter. Test names should start with lowercase unless it starts with the name of a technology, architecture, ISA etc. This first patch addresses cases of test names output explicitly via xfail, kfail, kpass, fail, pass, unsupported, untested and also names set with the pattern "set test" and "set testname". gdb/testsuite/ChangeLog: 2016-12-01 Luis Machado <lgustavo@codesourcery.com> Fix test names starting with uppercase throughout all the files below. * gdb.ada/array_return.exp * gdb.ada/catch_ex.exp * gdb.ada/info_exc.exp * gdb.ada/mi_catch_ex.exp * gdb.ada/mi_dyn_arr.exp * gdb.ada/mi_ex_cond.exp * gdb.ada/mi_exc_info.exp * gdb.ada/mi_interface.exp * gdb.ada/mi_task_arg.exp * gdb.ada/mi_task_info.exp * gdb.ada/mi_var_array.exp * gdb.arch/alpha-step.exp * gdb.arch/amd64-disp-step.exp * gdb.arch/arm-disp-step.exp * gdb.arch/disp-step-insn-reloc.exp * gdb.arch/e500-prologue.exp * gdb.arch/ftrace-insn-reloc.exp * gdb.arch/gdb1558.exp * gdb.arch/i386-bp_permanent.exp * gdb.arch/i386-disp-step.exp * gdb.arch/i386-float.exp * gdb.arch/i386-gnu-cfi.exp * gdb.arch/ia64-breakpoint-shadow.exp * gdb.arch/mips16-thunks.exp * gdb.arch/pa-nullify.exp * gdb.arch/powerpc-aix-prologue.exp * gdb.arch/powerpc-power.exp * gdb.arch/ppc-dfp.exp * gdb.arch/s390-tdbregs.exp * gdb.arch/spu-info.exp * gdb.arch/spu-ls.exp * gdb.arch/thumb-bx-pc.exp * gdb.base/advance.exp * gdb.base/annota-input-while-running.exp * gdb.base/arrayidx.exp * gdb.base/asmlabel.exp * gdb.base/async.exp * gdb.base/attach-wait-input.exp * gdb.base/auto-connect-native-target.exp * gdb.base/batch-preserve-term-settings.exp * gdb.base/bfp-test.exp * gdb.base/bigcore.exp * gdb.base/bp-permanent.exp * gdb.base/break-always.exp * gdb.base/break-fun-addr.exp * gdb.base/break-idempotent.exp * gdb.base/break-main-file-remove-fail.exp * gdb.base/break-probes.exp * gdb.base/break-unload-file.exp * gdb.base/break.exp * gdb.base/call-ar-st.exp * gdb.base/call-rt-st.exp * gdb.base/call-sc.exp * gdb.base/call-signal-resume.exp * gdb.base/call-strs.exp * gdb.base/callexit.exp * gdb.base/callfuncs.exp * gdb.base/catch-gdb-caused-signals.exp * gdb.base/catch-signal-siginfo-cond.exp * gdb.base/catch-syscall.exp * gdb.base/compare-sections.exp * gdb.base/cond-eval-mode.exp * gdb.base/condbreak-call-false.exp * gdb.base/consecutive-step-over.exp * gdb.base/cursal.exp * gdb.base/disabled-location.exp * gdb.base/disasm-end-cu.exp * gdb.base/display.exp * gdb.base/double-prompt-target-event-error.exp * gdb.base/dprintf-bp-same-addr.exp * gdb.base/dprintf-detach.exp * gdb.base/dprintf-next.exp * gdb.base/dprintf-non-stop.exp * gdb.base/dprintf-pending.exp * gdb.base/dso2dso.exp * gdb.base/ending-run.exp * gdb.base/enum_cond.exp * gdb.base/examine-backward.exp * gdb.base/exe-lock.exp * gdb.base/exec-invalid-sysroot.exp * gdb.base/execl-update-breakpoints.exp * gdb.base/execution-termios.exp * gdb.base/fileio.exp * gdb.base/fixsection.exp * gdb.base/foll-exec-mode.exp * gdb.base/foll-exec.exp * gdb.base/fork-running-state.exp * gdb.base/frame-args.exp * gdb.base/fullpath-expand.exp * gdb.base/func-ptr.exp * gdb.base/gcore-relro-pie.exp * gdb.base/gdb1090.exp * gdb.base/gdb1555.exp * gdb.base/global-var-nested-by-dso.exp * gdb.base/gnu-ifunc.exp * gdb.base/hbreak-in-shr-unsupported.exp * gdb.base/hbreak-unmapped.exp * gdb.base/hook-stop.exp * gdb.base/infcall-input.exp * gdb.base/info-fun.exp * gdb.base/info-shared.exp * gdb.base/interrupt-noterm.exp * gdb.base/jit-so.exp * gdb.base/jit.exp * gdb.base/line-symtabs.exp * gdb.base/list.exp * gdb.base/longjmp.exp * gdb.base/macscp.exp * gdb.base/max-value-size.exp * gdb.base/nodebug.exp * gdb.base/nofield.exp * gdb.base/overlays.exp * gdb.base/paginate-after-ctrl-c-running.exp * gdb.base/paginate-bg-execution.exp * gdb.base/paginate-inferior-exit.exp * gdb.base/pending.exp * gdb.base/pr11022.exp * gdb.base/printcmds.exp * gdb.base/ptr-typedef.exp * gdb.base/ptype.exp * gdb.base/randomize.exp * gdb.base/range-stepping.exp * gdb.base/realname-expand.exp * gdb.base/relativedebug.exp * gdb.base/remote.exp * gdb.base/savedregs.exp * gdb.base/sepdebug.exp * gdb.base/set-noassign.exp * gdb.base/shlib-call.exp * gdb.base/shreloc.exp * gdb.base/sigaltstack.exp * gdb.base/sigbpt.exp * gdb.base/siginfo-addr.exp * gdb.base/siginfo-obj.exp * gdb.base/siginfo-thread.exp * gdb.base/signest.exp * gdb.base/signull.exp * gdb.base/sigrepeat.exp * gdb.base/skip.exp * gdb.base/so-impl-ld.exp * gdb.base/solib-corrupted.exp * gdb.base/solib-disc.exp * gdb.base/solib-display.exp * gdb.base/solib-overlap.exp * gdb.base/solib-search.exp * gdb.base/solib-symbol.exp * gdb.base/source-execution.exp * gdb.base/sss-bp-on-user-bp-2.exp * gdb.base/sss-bp-on-user-bp.exp * gdb.base/stack-checking.exp * gdb.base/stale-infcall.exp * gdb.base/step-break.exp * gdb.base/step-line.exp * gdb.base/step-over-exit.exp * gdb.base/step-test.exp * gdb.base/structs.exp * gdb.base/sym-file.exp * gdb.base/symtab-search-order.exp * gdb.base/term.exp * gdb.base/type-opaque.exp * gdb.base/unload.exp * gdb.base/until-nodebug.exp * gdb.base/until.exp * gdb.base/unwindonsignal.exp * gdb.base/watch-cond.exp * gdb.base/watch-non-mem.exp * gdb.base/watch_thread_num.exp * gdb.base/watchpoint-reuse-slot.exp * gdb.base/watchpoint-solib.exp * gdb.base/watchpoint.exp * gdb.btrace/dlopen.exp * gdb.cell/arch.exp * gdb.cell/break.exp * gdb.cell/bt.exp * gdb.cell/core.exp * gdb.cell/data.exp * gdb.cell/dwarfaddr.exp * gdb.cell/ea-cache.exp * gdb.cell/ea-standalone.exp * gdb.cell/ea-test.exp * gdb.cell/f-regs.exp * gdb.cell/fork.exp * gdb.cell/gcore.exp * gdb.cell/mem-access.exp * gdb.cell/ptype.exp * gdb.cell/registers.exp * gdb.cell/sizeof.exp * gdb.cell/solib-symbol.exp * gdb.cell/solib.exp * gdb.compile/compile-tls.exp * gdb.cp/exception.exp * gdb.cp/gdb2495.exp * gdb.cp/local.exp * gdb.cp/mb-inline.exp * gdb.cp/mb-templates.exp * gdb.cp/pr10687.exp * gdb.cp/pr9167.exp * gdb.cp/scope-err.exp * gdb.cp/templates.exp * gdb.cp/virtfunc.exp * gdb.dwarf2/dw2-dir-file-name.exp * gdb.dwarf2/dw2-single-line-discriminators.exp * gdb.fortran/complex.exp * gdb.fortran/library-module.exp * gdb.guile/guile.exp * gdb.guile/scm-cmd.exp * gdb.guile/scm-frame-inline.exp * gdb.guile/scm-objfile.exp * gdb.guile/scm-pretty-print.exp * gdb.guile/scm-symbol.exp * gdb.guile/scm-type.exp * gdb.guile/scm-value.exp * gdb.linespec/keywords.exp * gdb.linespec/ls-errs.exp * gdb.linespec/macro-relative.exp * gdb.linespec/thread.exp * gdb.mi/mi-breakpoint-changed.exp * gdb.mi/mi-dprintf-pending.exp * gdb.mi/mi-fullname-deleted.exp * gdb.mi/mi-logging.exp * gdb.mi/mi-pending.exp * gdb.mi/mi-solib.exp * gdb.mi/new-ui-mi-sync.exp * gdb.mi/user-selected-context-sync.exp * gdb.multi/dummy-frame-restore.exp * gdb.multi/multi-arch-exec.exp * gdb.multi/remove-inferiors.exp * gdb.multi/watchpoint-multi-exit.exp * gdb.opt/solib-intra-step.exp * gdb.perf/backtrace.exp * gdb.perf/single-step.exp * gdb.perf/skip-command.exp * gdb.perf/skip-prologue.exp * gdb.perf/solib.exp * gdb.python/lib-types.exp * gdb.python/py-as-string.exp * gdb.python/py-bad-printers.exp * gdb.python/py-block.exp * gdb.python/py-breakpoint.exp * gdb.python/py-cmd.exp * gdb.python/py-events.exp * gdb.python/py-evthreads.exp * gdb.python/py-finish-breakpoint.exp * gdb.python/py-finish-breakpoint2.exp * gdb.python/py-frame-inline.exp * gdb.python/py-frame.exp * gdb.python/py-inferior.exp * gdb.python/py-infthread.exp * gdb.python/py-mi.exp * gdb.python/py-objfile.exp * gdb.python/py-pp-maint.exp * gdb.python/py-pp-registration.exp * gdb.python/py-prettyprint.exp * gdb.python/py-recurse-unwind.exp * gdb.python/py-shared.exp * gdb.python/py-symbol.exp * gdb.python/py-symtab.exp * gdb.python/py-template.exp * gdb.python/py-type.exp * gdb.python/py-unwind-maint.exp * gdb.python/py-unwind.exp * gdb.python/py-value.exp * gdb.python/python.exp * gdb.reverse/finish-reverse-bkpt.exp * gdb.reverse/insn-reverse.exp * gdb.reverse/next-reverse-bkpt-over-sr.exp * gdb.reverse/solib-precsave.exp * gdb.reverse/solib-reverse.exp * gdb.stabs/gdb11479.exp * gdb.stabs/weird.exp * gdb.threads/fork-child-threads.exp * gdb.threads/fork-plus-threads.exp * gdb.threads/fork-thread-pending.exp * gdb.threads/forking-threads-plus-breakpoint.exp * gdb.threads/hand-call-in-threads.exp * gdb.threads/interrupted-hand-call.exp * gdb.threads/linux-dp.exp * gdb.threads/local-watch-wrong-thread.exp * gdb.threads/next-while-other-thread-longjmps.exp * gdb.threads/non-ldr-exit.exp * gdb.threads/pending-step.exp * gdb.threads/print-threads.exp * gdb.threads/process-dies-while-detaching.exp * gdb.threads/process-dies-while-handling-bp.exp * gdb.threads/pthreads.exp * gdb.threads/queue-signal.exp * gdb.threads/reconnect-signal.exp * gdb.threads/signal-command-handle-nopass.exp * gdb.threads/signal-command-multiple-signals-pending.exp * gdb.threads/signal-delivered-right-thread.exp * gdb.threads/signal-sigtrap.exp * gdb.threads/sigthread.exp * gdb.threads/staticthreads.exp * gdb.threads/stepi-random-signal.exp * gdb.threads/thread-unwindonsignal.exp * gdb.threads/thread_check.exp * gdb.threads/thread_events.exp * gdb.threads/tid-reuse.exp * gdb.threads/tls-nodebug.exp * gdb.threads/tls-shared.exp * gdb.threads/tls-so_extern.exp * gdb.threads/tls.exp * gdb.threads/wp-replication.exp * gdb.trace/actions-changed.exp * gdb.trace/actions.exp * gdb.trace/backtrace.exp * gdb.trace/change-loc.exp * gdb.trace/collection.exp * gdb.trace/deltrace.exp * gdb.trace/disconnected-tracing.exp * gdb.trace/entry-values.exp * gdb.trace/ftrace-lock.exp * gdb.trace/ftrace.exp * gdb.trace/infotrace.exp * gdb.trace/mi-trace-frame-collected.exp * gdb.trace/mi-trace-unavailable.exp * gdb.trace/mi-traceframe-changed.exp * gdb.trace/mi-tracepoint-changed.exp * gdb.trace/mi-tsv-changed.exp * gdb.trace/no-attach-trace.exp * gdb.trace/packetlen.exp * gdb.trace/passc-dyn.exp * gdb.trace/passcount.exp * gdb.trace/pending.exp * gdb.trace/pr16508.exp * gdb.trace/qtro.exp * gdb.trace/range-stepping.exp * gdb.trace/read-memory.exp * gdb.trace/report.exp * gdb.trace/save-trace.exp * gdb.trace/signal.exp * gdb.trace/stap-trace.exp * gdb.trace/status-stop.exp * gdb.trace/strace.exp * gdb.trace/tfile.exp * gdb.trace/tfind.exp * gdb.trace/trace-break.exp * gdb.trace/trace-condition.exp * gdb.trace/trace-enable-disable.exp * gdb.trace/trace-mt.exp * gdb.trace/tracecmd.exp * gdb.trace/tracefile-pseudo-reg.exp * gdb.trace/tspeed.exp * gdb.trace/tstatus.exp * gdb.trace/tsv.exp * gdb.trace/unavailable.exp * gdb.trace/while-dyn.exp * gdb.trace/while-stepping.exp * lib/gdb-guile.exp * lib/gdb.exp * lib/mi-support.exp * lib/pascal.exp * lib/perftest.exp * lib/prelink-support.exp * lib/selftest-support.exp
2016-12-01 21:40:05 +01:00
fail "can't run to main"
Always pass signals to the right thread Currently, GDB can pass a signal to the wrong thread in several different but related scenarios. E.g., if thread 1 stops for signal SIGFOO, the user switches to thread 2, and then issues "continue", SIGFOO is actually delivered to thread 2, not thread 1. This obviously messes up programs that use pthread_kill to send signals to specific threads. This has been a known issue for a long while. Back in 2008 when I made stop_signal be per-thread (2020b7ab), I kept the behavior -- see code in 'proceed' being removed -- wanting to come back to it later. The time has finally come now. The patch fixes this -- on resumption, intercepted signals are always delivered to the thread that had intercepted them. Another example: if thread 1 stops for a breakpoint, the user switches to thread 2, and then issues "signal SIGFOO", SIGFOO is actually delivered to thread 1, not thread 2, because 'proceed' first switches to thread 1 to step over its breakpoint... If the user deletes the breakpoint before issuing "signal FOO", then the signal is delivered to thread 2 (the current thread). "signal SIGFOO" can be used for two things: inject a signal in the program while the program/thread had stopped for none, bypassing "handle nopass"; or changing/suppressing a signal the program had stopped for. These scenarios are really two faces of the same coin, and GDB can't really guess what the user is trying to do. GDB might have intercepted signals in more than one thread even (see the new signal-command-multiple-signals-pending.exp test). At least in the inject case, it's obviously clear to me that the user means to deliver the signal to the currently selected thread, so best is to make the command's behavior consistent and easy to explain. Then, if the user is trying to suppress/change a signal the program had stopped for instead of injecting a new signal, but, the user had changed threads meanwhile, then she will be surprised that with: (gdb) continue Thread 1 stopped for signal SIGFOO. (gdb) thread 2 (gdb) signal SIGBAR ... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2 (with scheduler-locking off, which is the default, because then "signal" or any other resumption command resumes all threads). So the patch makes GDB detect that, and ask for confirmation: (gdb) thread 1 [Switching to thread 1 (Thread 10979)] (gdb) signal SIGUSR2 Note: Thread 3 previously stopped with signal SIGUSR2, User defined signal 2. Thread 2 previously stopped with signal SIGUSR1, User defined signal 1. Continuing thread 1 (the current thread) with specified signal will still deliver the signals noted above to their respective threads. Continue anyway? (y or n) All these scenarios are covered by the new tests. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-07-25 Pedro Alves <palves@redhat.com> * NEWS: Mention signal passing and "signal" command changes. * gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend comment. * breakpoint.c (until_break_command): Adjust clear_proceed_status call. * infcall.c (run_inferior_call): Adjust clear_proceed_status call. * infcmd.c (proceed_thread_callback, continue_1, step_once) (jump_command): Adjust clear_proceed_status call. (signal_command): Warn if other thread that are resumed have signals that will be delivered. Adjust clear_proceed_status call. (until_next_command, finish_command) (proceed_after_attach_callback, attach_command_post_wait) (attach_command): Adjust clear_proceed_status call. * infrun.c (proceed_after_vfork_done): Likewise. (proceed_after_attach_callback): Adjust comment. (clear_proceed_status_thread): Clear stop_signal if not in pass state. (clear_proceed_status_callback): Delete. (clear_proceed_status): New 'step' parameter. Only clear the proceed status of threads the command being prepared is about to resume. (proceed): If passed in an explicit signal, override stop_signal with it. Don't pass the last stop signal to the thread we're resuming. (init_wait_for_inferior): Adjust clear_proceed_status call. (switch_back_to_stepped_thread): Clear the signal if it should not be passed. * infrun.h (clear_proceed_status): New 'step' parameter. (user_visible_resume_ptid): Add comment. * linux-nat.c (linux_nat_resume_callback): Don't check whether the signal is in pass state. * remote.c (append_pending_thread_resumptions): Likewise. * mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call. gdb/doc/ 2014-07-25 Pedro Alves <palves@redhat.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Signaling) <signal command>: Explain what happens with multi-threaded programs. gdb/testsuite/ 2014-07-25 Pedro Alves <palves@redhat.com> * gdb.threads/signal-command-handle-nopass.c: New file. * gdb.threads/signal-command-handle-nopass.exp: New file. * gdb.threads/signal-command-multiple-signals-pending.c: New file. * gdb.threads/signal-command-multiple-signals-pending.exp: New file. * gdb.threads/signal-delivered-right-thread.c: New file. * gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 17:57:31 +02:00
return 0
}
gdb_test "handle SIGUSR1 stop print nopass"
gdb_test "b thread_function" "Breakpoint .* at .*$srcfile.*"
gdb_test "continue" "thread_function.*" "stopped in thread"
# Thread 2 is stopped at a breakpoint. If we leave the
# breakpoint in place, GDB needs to move thread 2 past the
# breakpoint before delivering the signal to thread 1. We
# want to be sure that GDB doesn't mistakenly deliver the
# signal to thread 1 while doing that.
if { $step_over == "no" } {
delete_breakpoints
}
gdb_test "break handler" "Breakpoint .* at .*$srcfile.*"
gdb_test "thread 1" "Switching to thread 1.*"
set pattern "\\\* 1\[ \t\]+Thread.*"
gdb_test "info threads" $pattern "thread 1 selected"
gdb_test "signal SIGUSR1" "handler .*"
# Make sure it was thread 1 that got the signal. Note we list
# all threads instead of just thread 1, so that if something
# goes wrong and another thread ends up selected, we can
# easily see which in the logs.
Always pass signals to the right thread Currently, GDB can pass a signal to the wrong thread in several different but related scenarios. E.g., if thread 1 stops for signal SIGFOO, the user switches to thread 2, and then issues "continue", SIGFOO is actually delivered to thread 2, not thread 1. This obviously messes up programs that use pthread_kill to send signals to specific threads. This has been a known issue for a long while. Back in 2008 when I made stop_signal be per-thread (2020b7ab), I kept the behavior -- see code in 'proceed' being removed -- wanting to come back to it later. The time has finally come now. The patch fixes this -- on resumption, intercepted signals are always delivered to the thread that had intercepted them. Another example: if thread 1 stops for a breakpoint, the user switches to thread 2, and then issues "signal SIGFOO", SIGFOO is actually delivered to thread 1, not thread 2, because 'proceed' first switches to thread 1 to step over its breakpoint... If the user deletes the breakpoint before issuing "signal FOO", then the signal is delivered to thread 2 (the current thread). "signal SIGFOO" can be used for two things: inject a signal in the program while the program/thread had stopped for none, bypassing "handle nopass"; or changing/suppressing a signal the program had stopped for. These scenarios are really two faces of the same coin, and GDB can't really guess what the user is trying to do. GDB might have intercepted signals in more than one thread even (see the new signal-command-multiple-signals-pending.exp test). At least in the inject case, it's obviously clear to me that the user means to deliver the signal to the currently selected thread, so best is to make the command's behavior consistent and easy to explain. Then, if the user is trying to suppress/change a signal the program had stopped for instead of injecting a new signal, but, the user had changed threads meanwhile, then she will be surprised that with: (gdb) continue Thread 1 stopped for signal SIGFOO. (gdb) thread 2 (gdb) signal SIGBAR ... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2 (with scheduler-locking off, which is the default, because then "signal" or any other resumption command resumes all threads). So the patch makes GDB detect that, and ask for confirmation: (gdb) thread 1 [Switching to thread 1 (Thread 10979)] (gdb) signal SIGUSR2 Note: Thread 3 previously stopped with signal SIGUSR2, User defined signal 2. Thread 2 previously stopped with signal SIGUSR1, User defined signal 1. Continuing thread 1 (the current thread) with specified signal will still deliver the signals noted above to their respective threads. Continue anyway? (y or n) All these scenarios are covered by the new tests. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-07-25 Pedro Alves <palves@redhat.com> * NEWS: Mention signal passing and "signal" command changes. * gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend comment. * breakpoint.c (until_break_command): Adjust clear_proceed_status call. * infcall.c (run_inferior_call): Adjust clear_proceed_status call. * infcmd.c (proceed_thread_callback, continue_1, step_once) (jump_command): Adjust clear_proceed_status call. (signal_command): Warn if other thread that are resumed have signals that will be delivered. Adjust clear_proceed_status call. (until_next_command, finish_command) (proceed_after_attach_callback, attach_command_post_wait) (attach_command): Adjust clear_proceed_status call. * infrun.c (proceed_after_vfork_done): Likewise. (proceed_after_attach_callback): Adjust comment. (clear_proceed_status_thread): Clear stop_signal if not in pass state. (clear_proceed_status_callback): Delete. (clear_proceed_status): New 'step' parameter. Only clear the proceed status of threads the command being prepared is about to resume. (proceed): If passed in an explicit signal, override stop_signal with it. Don't pass the last stop signal to the thread we're resuming. (init_wait_for_inferior): Adjust clear_proceed_status call. (switch_back_to_stepped_thread): Clear the signal if it should not be passed. * infrun.h (clear_proceed_status): New 'step' parameter. (user_visible_resume_ptid): Add comment. * linux-nat.c (linux_nat_resume_callback): Don't check whether the signal is in pass state. * remote.c (append_pending_thread_resumptions): Likewise. * mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call. gdb/doc/ 2014-07-25 Pedro Alves <palves@redhat.com> Eli Zaretskii <eliz@gnu.org> * gdb.texinfo (Signaling) <signal command>: Explain what happens with multi-threaded programs. gdb/testsuite/ 2014-07-25 Pedro Alves <palves@redhat.com> * gdb.threads/signal-command-handle-nopass.c: New file. * gdb.threads/signal-command-handle-nopass.exp: New file. * gdb.threads/signal-command-multiple-signals-pending.c: New file. * gdb.threads/signal-command-multiple-signals-pending.exp: New file. * gdb.threads/signal-delivered-right-thread.c: New file. * gdb.threads/signal-delivered-right-thread.exp: New file.
2014-07-25 17:57:31 +02:00
gdb_test "info threads" $pattern "thread 1 got the signal"
}
}
foreach stepover {"yes" "no"} {
test $stepover
}