binutils-gdb/gdb/testsuite/gdb.base/sigstep.exp

589 lines
17 KiB
Plaintext
Raw Normal View History

# Copyright 2004-2017 Free Software Foundation, Inc.
# 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/>.
# The program sigstep.c creates a very simple backtrace containing one
# signal handler and signal trampoline. A flag is set and then the
# handler returns. This is repeated at infinitum.
# This test runs the program up to the signal handler, and then
# attempts to step/next out of the handler and back into main.
if [target_info exists gdb,nosignals] {
verbose "Skipping sigstep.exp because of nosignals."
continue
}
standard_testfile
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
if {[build_executable $testfile.exp $testfile $srcfile debug]} {
Fix more cases of improper test names I noticed more occurrences of improper test names. The rather mechanical, tedious and large patch below addresses, hopefully, most of the leftover cases. As usual, another pair of eyes is welcome to check if missed something or did an invalid substitution. This patch also fixes the prepare_for_testing calls to pass proper test names. gdb/testsuite/ChangeLog: 2016-12-23 Luis Machado <lgustavo@codesourcery.com> Fix test names for the following files: * gdb.ada/exec_changed.exp * gdb.ada/info_types.exp * gdb.arch/aarch64-atomic-inst.exp * gdb.arch/aarch64-fp.exp * gdb.arch/altivec-abi.exp * gdb.arch/altivec-regs.exp * gdb.arch/amd64-byte.exp * gdb.arch/amd64-disp-step.exp * gdb.arch/amd64-dword.exp * gdb.arch/amd64-entry-value-inline.exp * gdb.arch/amd64-entry-value-param.exp * gdb.arch/amd64-entry-value-paramref.exp * gdb.arch/amd64-entry-value.exp * gdb.arch/amd64-i386-address.exp * gdb.arch/amd64-invalid-stack-middle.exp * gdb.arch/amd64-invalid-stack-top.exp * gdb.arch/amd64-optimout-repeat.exp * gdb.arch/amd64-prologue-skip.exp * gdb.arch/amd64-prologue-xmm.exp * gdb.arch/amd64-stap-special-operands.exp * gdb.arch/amd64-stap-wrong-subexp.exp * gdb.arch/amd64-tailcall-cxx.exp * gdb.arch/amd64-tailcall-noret.exp * gdb.arch/amd64-tailcall-ret.exp * gdb.arch/amd64-tailcall-self.exp * gdb.arch/amd64-word.exp * gdb.arch/arm-bl-branch-dest.exp * gdb.arch/arm-disp-step.exp * gdb.arch/arm-neon.exp * gdb.arch/arm-single-step-kernel-helper.exp * gdb.arch/avr-flash-qualifier.exp * gdb.arch/disp-step-insn-reloc.exp * gdb.arch/e500-abi.exp * gdb.arch/e500-regs.exp * gdb.arch/ftrace-insn-reloc.exp * gdb.arch/i386-avx512.exp * gdb.arch/i386-bp_permanent.exp * gdb.arch/i386-byte.exp * gdb.arch/i386-cfi-notcurrent.exp * gdb.arch/i386-disp-step.exp * gdb.arch/i386-dr3-watch.exp * gdb.arch/i386-float.exp * gdb.arch/i386-gnu-cfi.exp * gdb.arch/i386-mpx-map.exp * gdb.arch/i386-mpx-sigsegv.exp * gdb.arch/i386-mpx-simple_segv.exp * gdb.arch/i386-mpx.exp * gdb.arch/i386-permbkpt.exp * gdb.arch/i386-prologue.exp * gdb.arch/i386-signal.exp * gdb.arch/i386-size-overlap.exp * gdb.arch/i386-unwind.exp * gdb.arch/i386-word.exp * gdb.arch/mips-fcr.exp * gdb.arch/powerpc-d128-regs.exp * gdb.arch/powerpc-stackless.exp * gdb.arch/ppc64-atomic-inst.exp * gdb.arch/s390-stackless.exp * gdb.arch/s390-tdbregs.exp * gdb.arch/s390-vregs.exp * gdb.arch/sparc-sysstep.exp * gdb.arch/thumb-bx-pc.exp * gdb.arch/thumb-singlestep.exp * gdb.arch/thumb2-it.exp * gdb.arch/vsx-regs.exp * gdb.asm/asm-source.exp * gdb.base/a2-run.exp * gdb.base/advance.exp * gdb.base/all-bin.exp * gdb.base/anon.exp * gdb.base/args.exp * gdb.base/arithmet.exp * gdb.base/async-shell.exp * gdb.base/async.exp * gdb.base/attach-pie-noexec.exp * gdb.base/attach-twice.exp * gdb.base/auto-load.exp * gdb.base/bang.exp * gdb.base/bitfields.exp * gdb.base/break-always.exp * gdb.base/break-caller-line.exp * gdb.base/break-entry.exp * gdb.base/break-inline.exp * gdb.base/break-on-linker-gcd-function.exp * gdb.base/break-probes.exp * gdb.base/break.exp * gdb.base/breakpoint-shadow.exp * gdb.base/call-ar-st.exp * gdb.base/call-sc.exp * gdb.base/call-signal-resume.exp * gdb.base/call-strs.exp * gdb.base/callfuncs.exp * gdb.base/catch-fork-static.exp * gdb.base/catch-gdb-caused-signals.exp * gdb.base/catch-load.exp * gdb.base/catch-signal-fork.exp * gdb.base/catch-signal.exp * gdb.base/catch-syscall.exp * gdb.base/charset.exp * gdb.base/checkpoint.exp * gdb.base/chng-syms.exp * gdb.base/code-expr.exp * gdb.base/code_elim.exp * gdb.base/commands.exp * gdb.base/completion.exp * gdb.base/complex.exp * gdb.base/cond-expr.exp * gdb.base/condbreak.exp * gdb.base/consecutive.exp * gdb.base/continue-all-already-running.exp * gdb.base/coredump-filter.exp * gdb.base/corefile.exp * gdb.base/dbx.exp * gdb.base/debug-expr.exp * gdb.base/define.exp * gdb.base/del.exp * gdb.base/disabled-location.exp * gdb.base/disasm-end-cu.exp * gdb.base/disasm-optim.exp * gdb.base/display.exp * gdb.base/duplicate-bp.exp * gdb.base/ena-dis-br.exp * gdb.base/ending-run.exp * gdb.base/enumval.exp * gdb.base/environ.exp * gdb.base/eu-strip-infcall.exp * gdb.base/eval-avoid-side-effects.exp * gdb.base/eval-skip.exp * gdb.base/exitsignal.exp * gdb.base/expand-psymtabs.exp * gdb.base/filesym.exp * gdb.base/find-unmapped.exp * gdb.base/finish.exp * gdb.base/float.exp * gdb.base/foll-exec-mode.exp * gdb.base/foll-exec.exp * gdb.base/foll-fork.exp * gdb.base/fortran-sym-case.exp * gdb.base/freebpcmd.exp * gdb.base/func-ptr.exp * gdb.base/func-ptrs.exp * gdb.base/funcargs.exp * gdb.base/gcore-buffer-overflow.exp * gdb.base/gcore-relro-pie.exp * gdb.base/gcore-relro.exp * gdb.base/gcore.exp * gdb.base/gdb1090.exp * gdb.base/gdb11530.exp * gdb.base/gdb11531.exp * gdb.base/gdb1821.exp * gdb.base/gdbindex-stabs.exp * gdb.base/gdbvars.exp * gdb.base/hbreak.exp * gdb.base/hbreak2.exp * gdb.base/included.exp * gdb.base/infcall-input.exp * gdb.base/inferior-died.exp * gdb.base/infnan.exp * gdb.base/info-macros.exp * gdb.base/info-os.exp * gdb.base/info-proc.exp * gdb.base/info-shared.exp * gdb.base/info-target.exp * gdb.base/infoline.exp * gdb.base/interp.exp * gdb.base/interrupt.exp * gdb.base/jit-reader.exp * gdb.base/jit-simple.exp * gdb.base/kill-after-signal.exp * gdb.base/kill-detach-inferiors-cmd.exp * gdb.base/label.exp * gdb.base/langs.exp * gdb.base/ldbl_e308.exp * gdb.base/line-symtabs.exp * gdb.base/linespecs.exp * gdb.base/list.exp * gdb.base/long_long.exp * gdb.base/longest-types.exp * gdb.base/maint.exp * gdb.base/max-value-size.exp * gdb.base/memattr.exp * gdb.base/mips_pro.exp * gdb.base/morestack.exp * gdb.base/moribund-step.exp * gdb.base/multi-forks.exp * gdb.base/nested-addr.exp * gdb.base/nextoverexit.exp * gdb.base/noreturn-finish.exp * gdb.base/noreturn-return.exp * gdb.base/nostdlib.exp * gdb.base/offsets.exp * gdb.base/opaque.exp * gdb.base/pc-fp.exp * gdb.base/permissions.exp * gdb.base/print-symbol-loading.exp * gdb.base/prologue-include.exp * gdb.base/psymtab.exp * gdb.base/ptype.exp * gdb.base/random-signal.exp * gdb.base/randomize.exp * gdb.base/range-stepping.exp * gdb.base/readline-ask.exp * gdb.base/recpar.exp * gdb.base/recurse.exp * gdb.base/relational.exp * gdb.base/restore.exp * gdb.base/return-nodebug.exp * gdb.base/return.exp * gdb.base/run-after-attach.exp * gdb.base/save-bp.exp * gdb.base/scope.exp * gdb.base/sect-cmd.exp * gdb.base/set-lang-auto.exp * gdb.base/set-noassign.exp * gdb.base/setvar.exp * gdb.base/sigall.exp * gdb.base/sigbpt.exp * gdb.base/siginfo-addr.exp * gdb.base/siginfo-infcall.exp * gdb.base/siginfo-obj.exp * gdb.base/siginfo.exp * gdb.base/signals-state-child.exp * gdb.base/signest.exp * gdb.base/sigstep.exp * gdb.base/sizeof.exp * gdb.base/skip.exp * gdb.base/solib-corrupted.exp * gdb.base/solib-nodir.exp * gdb.base/solib-search.exp * gdb.base/stack-checking.exp * gdb.base/stale-infcall.exp * gdb.base/stap-probe.exp * gdb.base/start.exp * gdb.base/step-break.exp * gdb.base/step-bt.exp * gdb.base/step-line.exp * gdb.base/step-over-exit.exp * gdb.base/step-over-syscall.exp * gdb.base/step-resume-infcall.exp * gdb.base/step-test.exp * gdb.base/store.exp * gdb.base/structs3.exp * gdb.base/sym-file.exp * gdb.base/symbol-without-target_section.exp * gdb.base/term.exp * gdb.base/testenv.exp * gdb.base/ui-redirect.exp * gdb.base/until.exp * gdb.base/unwindonsignal.exp * gdb.base/value-double-free.exp * gdb.base/vla-datatypes.exp * gdb.base/vla-ptr.exp * gdb.base/vla-sideeffect.exp * gdb.base/volatile.exp * gdb.base/watch-cond-infcall.exp * gdb.base/watch-cond.exp * gdb.base/watch-non-mem.exp * gdb.base/watch-read.exp * gdb.base/watch-vfork.exp * gdb.base/watchpoint-cond-gone.exp * gdb.base/watchpoint-delete.exp * gdb.base/watchpoint-hw-hit-once.exp * gdb.base/watchpoint-hw.exp * gdb.base/watchpoint-stops-at-right-insn.exp * gdb.base/watchpoints.exp * gdb.base/wchar.exp * gdb.base/whatis-exp.exp * gdb.btrace/buffer-size.exp * gdb.btrace/data.exp * gdb.btrace/delta.exp * gdb.btrace/dlopen.exp * gdb.btrace/enable.exp * gdb.btrace/exception.exp * gdb.btrace/function_call_history.exp * gdb.btrace/gcore.exp * gdb.btrace/instruction_history.exp * gdb.btrace/nohist.exp * gdb.btrace/reconnect.exp * gdb.btrace/record_goto-step.exp * gdb.btrace/record_goto.exp * gdb.btrace/rn-dl-bind.exp * gdb.btrace/segv.exp * gdb.btrace/step.exp * gdb.btrace/stepi.exp * gdb.btrace/tailcall-only.exp * gdb.btrace/tailcall.exp * gdb.btrace/tsx.exp * gdb.btrace/unknown_functions.exp * gdb.btrace/vdso.exp * gdb.compile/compile-ifunc.exp * gdb.compile/compile-ops.exp * gdb.compile/compile-print.exp * gdb.compile/compile-setjmp.exp * gdb.cp/abstract-origin.exp * gdb.cp/ambiguous.exp * gdb.cp/annota2.exp * gdb.cp/annota3.exp * gdb.cp/anon-ns.exp * gdb.cp/anon-struct.exp * gdb.cp/anon-union.exp * gdb.cp/arg-reference.exp * gdb.cp/baseenum.exp * gdb.cp/bool.exp * gdb.cp/breakpoint.exp * gdb.cp/bs15503.exp * gdb.cp/call-c.exp * gdb.cp/casts.exp * gdb.cp/chained-calls.exp * gdb.cp/class2.exp * gdb.cp/classes.exp * gdb.cp/cmpd-minsyms.exp * gdb.cp/converts.exp * gdb.cp/cp-relocate.exp * gdb.cp/cpcompletion.exp * gdb.cp/cpexprs.exp * gdb.cp/cplabel.exp * gdb.cp/cplusfuncs.exp * gdb.cp/cpsizeof.exp * gdb.cp/ctti.exp * gdb.cp/derivation.exp * gdb.cp/destrprint.exp * gdb.cp/dispcxx.exp * gdb.cp/enum-class.exp * gdb.cp/exception.exp * gdb.cp/exceptprint.exp * gdb.cp/expand-psymtabs-cxx.exp * gdb.cp/expand-sals.exp * gdb.cp/extern-c.exp * gdb.cp/filename.exp * gdb.cp/formatted-ref.exp * gdb.cp/fpointer.exp * gdb.cp/gdb1355.exp * gdb.cp/gdb2495.exp * gdb.cp/hang.exp * gdb.cp/impl-this.exp * gdb.cp/infcall-dlopen.exp * gdb.cp/inherit.exp * gdb.cp/iostream.exp * gdb.cp/koenig.exp * gdb.cp/local.exp * gdb.cp/m-data.exp * gdb.cp/m-static.exp * gdb.cp/mb-ctor.exp * gdb.cp/mb-inline.exp * gdb.cp/mb-templates.exp * gdb.cp/member-name.exp * gdb.cp/member-ptr.exp * gdb.cp/meth-typedefs.exp * gdb.cp/method.exp * gdb.cp/method2.exp * gdb.cp/minsym-fallback.exp * gdb.cp/misc.exp * gdb.cp/namelessclass.exp * gdb.cp/namespace-enum.exp * gdb.cp/namespace-nested-import.exp * gdb.cp/namespace.exp * gdb.cp/nextoverthrow.exp * gdb.cp/no-dmgl-verbose.exp * gdb.cp/non-trivial-retval.exp * gdb.cp/noparam.exp * gdb.cp/nsdecl.exp * gdb.cp/nsimport.exp * gdb.cp/nsnested.exp * gdb.cp/nsnoimports.exp * gdb.cp/nsrecurs.exp * gdb.cp/nsstress.exp * gdb.cp/nsusing.exp * gdb.cp/operator.exp * gdb.cp/oranking.exp * gdb.cp/overload-const.exp * gdb.cp/overload.exp * gdb.cp/ovldbreak.exp * gdb.cp/ovsrch.exp * gdb.cp/paren-type.exp * gdb.cp/parse-lang.exp * gdb.cp/pass-by-ref.exp * gdb.cp/pr-1023.exp * gdb.cp/pr-1210.exp * gdb.cp/pr-574.exp * gdb.cp/pr10687.exp * gdb.cp/pr12028.exp * gdb.cp/pr17132.exp * gdb.cp/pr17494.exp * gdb.cp/pr9067.exp * gdb.cp/pr9167.exp * gdb.cp/pr9631.exp * gdb.cp/printmethod.exp * gdb.cp/psmang.exp * gdb.cp/psymtab-parameter.exp * gdb.cp/ptype-cv-cp.exp * gdb.cp/ptype-flags.exp * gdb.cp/re-set-overloaded.exp * gdb.cp/ref-types.exp * gdb.cp/rtti.exp * gdb.cp/scope-err.exp * gdb.cp/shadow.exp * gdb.cp/smartp.exp * gdb.cp/static-method.exp * gdb.cp/static-print-quit.exp * gdb.cp/temargs.exp * gdb.cp/templates.exp * gdb.cp/try_catch.exp * gdb.cp/typedef-operator.exp * gdb.cp/typeid.exp * gdb.cp/userdef.exp * gdb.cp/using-crash.exp * gdb.cp/var-tag.exp * gdb.cp/virtbase.exp * gdb.cp/virtfunc.exp * gdb.cp/virtfunc2.exp * gdb.cp/vla-cxx.exp * gdb.disasm/t01_mov.exp * gdb.disasm/t02_mova.exp * gdb.disasm/t03_add.exp * gdb.disasm/t04_sub.exp * gdb.disasm/t05_cmp.exp * gdb.disasm/t06_ari2.exp * gdb.disasm/t07_ari3.exp * gdb.disasm/t08_or.exp * gdb.disasm/t09_xor.exp * gdb.disasm/t10_and.exp * gdb.disasm/t11_logs.exp * gdb.disasm/t12_bit.exp * gdb.disasm/t13_otr.exp * gdb.dlang/circular.exp * gdb.dwarf2/arr-stride.exp * gdb.dwarf2/arr-subrange.exp * gdb.dwarf2/atomic-type.exp * gdb.dwarf2/bad-regnum.exp * gdb.dwarf2/bitfield-parent-optimized-out.exp * gdb.dwarf2/callframecfa.exp * gdb.dwarf2/clztest.exp * gdb.dwarf2/corrupt.exp * gdb.dwarf2/data-loc.exp * gdb.dwarf2/dup-psym.exp * gdb.dwarf2/dw2-anon-mptr.exp * gdb.dwarf2/dw2-anonymous-func.exp * gdb.dwarf2/dw2-bad-mips-linkage-name.exp * gdb.dwarf2/dw2-bad-unresolved.exp * gdb.dwarf2/dw2-basic.exp * gdb.dwarf2/dw2-canonicalize-type.exp * gdb.dwarf2/dw2-case-insensitive.exp * gdb.dwarf2/dw2-common-block.exp * gdb.dwarf2/dw2-compdir-oldgcc.exp * gdb.dwarf2/dw2-compressed.exp * gdb.dwarf2/dw2-const.exp * gdb.dwarf2/dw2-cp-infcall-ref-static.exp * gdb.dwarf2/dw2-cu-size.exp * gdb.dwarf2/dw2-dup-frame.exp * gdb.dwarf2/dw2-entry-value.exp * gdb.dwarf2/dw2-icycle.exp * gdb.dwarf2/dw2-ifort-parameter.exp * gdb.dwarf2/dw2-inline-break.exp * gdb.dwarf2/dw2-inline-param.exp * gdb.dwarf2/dw2-intercu.exp * gdb.dwarf2/dw2-intermix.exp * gdb.dwarf2/dw2-lexical-block-bare.exp * gdb.dwarf2/dw2-linkage-name-trust.exp * gdb.dwarf2/dw2-minsym-in-cu.exp * gdb.dwarf2/dw2-noloc.exp * gdb.dwarf2/dw2-op-call.exp * gdb.dwarf2/dw2-op-out-param.exp * gdb.dwarf2/dw2-opt-structptr.exp * gdb.dwarf2/dw2-param-error.exp * gdb.dwarf2/dw2-producer.exp * gdb.dwarf2/dw2-ranges-base.exp * gdb.dwarf2/dw2-ref-missing-frame.exp * gdb.dwarf2/dw2-reg-undefined.exp * gdb.dwarf2/dw2-regno-invalid.exp * gdb.dwarf2/dw2-restore.exp * gdb.dwarf2/dw2-restrict.exp * gdb.dwarf2/dw2-single-line-discriminators.exp * gdb.dwarf2/dw2-strp.exp * gdb.dwarf2/dw2-undefined-ret-addr.exp * gdb.dwarf2/dw2-unresolved.exp * gdb.dwarf2/dw2-var-zero-addr.exp * gdb.dwarf2/dw4-sig-types.exp * gdb.dwarf2/dwz.exp * gdb.dwarf2/dynarr-ptr.exp * gdb.dwarf2/enum-type.exp * gdb.dwarf2/gdb-index.exp * gdb.dwarf2/implptr-64bit.exp * gdb.dwarf2/implptr-optimized-out.exp * gdb.dwarf2/implptr.exp * gdb.dwarf2/implref-array.exp * gdb.dwarf2/implref-const.exp * gdb.dwarf2/implref-global.exp * gdb.dwarf2/implref-struct.exp * gdb.dwarf2/mac-fileno.exp * gdb.dwarf2/main-subprogram.exp * gdb.dwarf2/member-ptr-forwardref.exp * gdb.dwarf2/method-ptr.exp * gdb.dwarf2/missing-sig-type.exp * gdb.dwarf2/nonvar-access.exp * gdb.dwarf2/opaque-type-lookup.exp * gdb.dwarf2/pieces-optimized-out.exp * gdb.dwarf2/pieces.exp * gdb.dwarf2/pr10770.exp * gdb.dwarf2/pr13961.exp * gdb.dwarf2/staticvirtual.exp * gdb.dwarf2/subrange.exp * gdb.dwarf2/symtab-producer.exp * gdb.dwarf2/trace-crash.exp * gdb.dwarf2/typeddwarf.exp * gdb.dwarf2/valop.exp * gdb.dwarf2/watch-notconst.exp * gdb.fortran/array-element.exp * gdb.fortran/charset.exp * gdb.fortran/common-block.exp * gdb.fortran/complex.exp * gdb.fortran/derived-type-function.exp * gdb.fortran/derived-type.exp * gdb.fortran/logical.exp * gdb.fortran/module.exp * gdb.fortran/multi-dim.exp * gdb.fortran/nested-funcs.exp * gdb.fortran/print-formatted.exp * gdb.fortran/subarray.exp * gdb.fortran/vla-alloc-assoc.exp * gdb.fortran/vla-datatypes.exp * gdb.fortran/vla-history.exp * gdb.fortran/vla-ptr-info.exp * gdb.fortran/vla-ptype-sub.exp * gdb.fortran/vla-ptype.exp * gdb.fortran/vla-sizeof.exp * gdb.fortran/vla-type.exp * gdb.fortran/vla-value-sub-arbitrary.exp * gdb.fortran/vla-value-sub-finish.exp * gdb.fortran/vla-value-sub.exp * gdb.fortran/vla-value.exp * gdb.fortran/whatis_type.exp * gdb.go/chan.exp * gdb.go/handcall.exp * gdb.go/hello.exp * gdb.go/integers.exp * gdb.go/methods.exp * gdb.go/package.exp * gdb.go/strings.exp * gdb.go/types.exp * gdb.go/unsafe.exp * gdb.guile/scm-arch.exp * gdb.guile/scm-block.exp * gdb.guile/scm-breakpoint.exp * gdb.guile/scm-cmd.exp * gdb.guile/scm-disasm.exp * gdb.guile/scm-equal.exp * gdb.guile/scm-frame-args.exp * gdb.guile/scm-frame-inline.exp * gdb.guile/scm-frame.exp * gdb.guile/scm-iterator.exp * gdb.guile/scm-math.exp * gdb.guile/scm-objfile.exp * gdb.guile/scm-ports.exp * gdb.guile/scm-symbol.exp * gdb.guile/scm-symtab.exp * gdb.guile/scm-value-cc.exp * gdb.guile/types-module.exp * gdb.linespec/break-ask.exp * gdb.linespec/cpexplicit.exp * gdb.linespec/explicit.exp * gdb.linespec/keywords.exp * gdb.linespec/linespec.exp * gdb.linespec/ls-dollar.exp * gdb.linespec/ls-errs.exp * gdb.linespec/skip-two.exp * gdb.linespec/thread.exp * gdb.mi/mi-async.exp * gdb.mi/mi-basics.exp * gdb.mi/mi-break.exp * gdb.mi/mi-catch-load.exp * gdb.mi/mi-cli.exp * gdb.mi/mi-cmd-param-changed.exp * gdb.mi/mi-console.exp * gdb.mi/mi-detach.exp * gdb.mi/mi-disassemble.exp * gdb.mi/mi-eval.exp * gdb.mi/mi-file-transfer.exp * gdb.mi/mi-file.exp * gdb.mi/mi-fill-memory.exp * gdb.mi/mi-inheritance-syntax-error.exp * gdb.mi/mi-linespec-err-cp.exp * gdb.mi/mi-logging.exp * gdb.mi/mi-memory-changed.exp * gdb.mi/mi-read-memory.exp * gdb.mi/mi-record-changed.exp * gdb.mi/mi-reg-undefined.exp * gdb.mi/mi-regs.exp * gdb.mi/mi-return.exp * gdb.mi/mi-reverse.exp * gdb.mi/mi-simplerun.exp * gdb.mi/mi-solib.exp * gdb.mi/mi-stack.exp * gdb.mi/mi-stepi.exp * gdb.mi/mi-syn-frame.exp * gdb.mi/mi-until.exp * gdb.mi/mi-var-block.exp * gdb.mi/mi-var-child.exp * gdb.mi/mi-var-cmd.exp * gdb.mi/mi-var-cp.exp * gdb.mi/mi-var-display.exp * gdb.mi/mi-var-invalidate.exp * gdb.mi/mi-var-list-children-invalid-grandchild.exp * gdb.mi/mi-vla-fortran.exp * gdb.mi/mi-watch.exp * gdb.mi/mi2-var-child.exp * gdb.mi/user-selected-context-sync.exp * gdb.modula2/unbounded-array.exp * gdb.multi/dummy-frame-restore.exp * gdb.multi/multi-arch-exec.exp * gdb.multi/multi-arch.exp * gdb.multi/tids.exp * gdb.multi/watchpoint-multi.exp * gdb.opencl/callfuncs.exp * gdb.opencl/convs_casts.exp * gdb.opencl/datatypes.exp * gdb.opencl/operators.exp * gdb.opencl/vec_comps.exp * gdb.opt/clobbered-registers-O2.exp * gdb.opt/inline-break.exp * gdb.opt/inline-bt.exp * gdb.opt/inline-cmds.exp * gdb.opt/inline-locals.exp * gdb.pascal/case-insensitive-symbols.exp * gdb.pascal/floats.exp * gdb.pascal/gdb11492.exp * gdb.python/lib-types.exp * gdb.python/py-arch.exp * gdb.python/py-as-string.exp * gdb.python/py-bad-printers.exp * gdb.python/py-block.exp * gdb.python/py-breakpoint-create-fail.exp * gdb.python/py-breakpoint.exp * gdb.python/py-caller-is.exp * gdb.python/py-cmd.exp * gdb.python/py-explore-cc.exp * gdb.python/py-explore.exp * gdb.python/py-finish-breakpoint.exp * gdb.python/py-finish-breakpoint2.exp * gdb.python/py-frame-args.exp * gdb.python/py-frame-inline.exp * gdb.python/py-frame.exp * gdb.python/py-framefilter-mi.exp * gdb.python/py-infthread.exp * gdb.python/py-lazy-string.exp * gdb.python/py-linetable.exp * gdb.python/py-mi-events.exp * gdb.python/py-mi-objfile.exp * gdb.python/py-mi.exp * gdb.python/py-objfile.exp * gdb.python/py-pp-integral.exp * gdb.python/py-pp-maint.exp * gdb.python/py-pp-re-notag.exp * gdb.python/py-pp-registration.exp * gdb.python/py-recurse-unwind.exp * gdb.python/py-strfns.exp * gdb.python/py-symbol.exp * gdb.python/py-symtab.exp * gdb.python/py-sync-interp.exp * gdb.python/py-typeprint.exp * gdb.python/py-unwind-maint.exp * gdb.python/py-unwind.exp * gdb.python/py-value-cc.exp * gdb.python/py-xmethods.exp * gdb.reverse/amd64-tailcall-reverse.exp * gdb.reverse/break-precsave.exp * gdb.reverse/break-reverse.exp * gdb.reverse/consecutive-precsave.exp * gdb.reverse/consecutive-reverse.exp * gdb.reverse/finish-precsave.exp * gdb.reverse/finish-reverse-bkpt.exp * gdb.reverse/finish-reverse.exp * gdb.reverse/fstatat-reverse.exp * gdb.reverse/getresuid-reverse.exp * gdb.reverse/i386-precsave.exp * gdb.reverse/i386-reverse.exp * gdb.reverse/i386-sse-reverse.exp * gdb.reverse/i387-env-reverse.exp * gdb.reverse/i387-stack-reverse.exp * gdb.reverse/insn-reverse.exp * gdb.reverse/machinestate-precsave.exp * gdb.reverse/machinestate.exp * gdb.reverse/next-reverse-bkpt-over-sr.exp * gdb.reverse/pipe-reverse.exp * gdb.reverse/readv-reverse.exp * gdb.reverse/recvmsg-reverse.exp * gdb.reverse/rerun-prec.exp * gdb.reverse/s390-mvcle.exp * gdb.reverse/step-precsave.exp * gdb.reverse/step-reverse.exp * gdb.reverse/time-reverse.exp * gdb.reverse/until-precsave.exp * gdb.reverse/until-reverse.exp * gdb.reverse/waitpid-reverse.exp * gdb.reverse/watch-precsave.exp * gdb.reverse/watch-reverse.exp * gdb.rust/generics.exp * gdb.rust/methods.exp * gdb.rust/modules.exp * gdb.rust/simple.exp * gdb.server/connect-with-no-symbol-file.exp * gdb.server/ext-attach.exp * gdb.server/ext-restart.exp * gdb.server/ext-wrapper.exp * gdb.server/file-transfer.exp * gdb.server/server-exec-info.exp * gdb.server/server-kill.exp * gdb.server/server-mon.exp * gdb.server/wrapper.exp * gdb.stabs/exclfwd.exp * gdb.stabs/gdb11479.exp * gdb.threads/clone-new-thread-event.exp * gdb.threads/corethreads.exp * gdb.threads/current-lwp-dead.exp * gdb.threads/dlopen-libpthread.exp * gdb.threads/gcore-thread.exp * gdb.threads/sigstep-threads.exp * gdb.threads/watchpoint-fork.exp * gdb.trace/actions-changed.exp * gdb.trace/backtrace.exp * gdb.trace/change-loc.exp * gdb.trace/circ.exp * gdb.trace/collection.exp * gdb.trace/disconnected-tracing.exp * gdb.trace/ftrace.exp * gdb.trace/mi-trace-frame-collected.exp * gdb.trace/mi-trace-unavailable.exp * gdb.trace/mi-traceframe-changed.exp * gdb.trace/mi-tsv-changed.exp * gdb.trace/no-attach-trace.exp * gdb.trace/passc-dyn.exp * gdb.trace/qtro.exp * gdb.trace/range-stepping.exp * gdb.trace/read-memory.exp * gdb.trace/save-trace.exp * gdb.trace/signal.exp * gdb.trace/status-stop.exp * gdb.trace/tfile.exp * gdb.trace/trace-break.exp * gdb.trace/trace-buffer-size.exp * gdb.trace/trace-condition.exp * gdb.trace/tracefile-pseudo-reg.exp * gdb.trace/tstatus.exp * gdb.trace/unavailable.exp * gdb.trace/while-dyn.exp * gdb.trace/while-stepping.exp
2016-12-23 17:52:18 +01:00
untested "failed to compile"
return -1
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
set clear_done [gdb_get_line_number {done = 0}]
set infinite_loop [gdb_get_line_number {while (!done)}]
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
set other_handler_location [gdb_get_line_number "other handler location"]
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Restart GDB, set a display showing $PC, and run to main.
proc restart {} {
global binfile
clean_restart $binfile
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
gdb_test "display/i \$pc"
runto_main
}
# Pass all the alarms straight through (but verbosely)
# gdb_test "handle SIGALRM print pass nostop"
# gdb_test "handle SIGVTALRM print pass nostop"
# gdb_test "handle SIGPROF print pass nostop"
# Run to the signal handler, validate the backtrace.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc validate_backtrace {} {
with_test_prefix "validate backtrace" {
restart
gdb_test "break handler"
gdb_test "continue" ".* handler .*" "continue to stepi handler"
gdb_test_sequence "bt" "backtrace for nexti" {
"\[\r\n\]+.0 \[^\r\n\]* handler "
"\[\r\n\]+.1 .signal handler called."
"\[\r\n\]+.2 \[^\r\n\]* main "
}
}
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
validate_backtrace
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
# Goes to handler using ENTER_CMD, runs IN_HANDLER while in the signal
# hander, and then steps out of the signal handler using EXIT_CMD.
proc advance { enter_cmd in_handler_prefix in_handler exit_cmd } {
gdb * infrun.c (print_exited_reason): Include inferior id and pid in message. gdb/testsuite * lib/opencl.exp (skip_opencl_tests): Update for exit message change. * lib/mi-support.exp (mi_gdb_test): Update for exit message change. * lib/gdb.exp (gdb_test_multiple): Update comment. Update for exit message change. (skip_altivec_tests): Update for exit message change. (skip_vsx_tests): Likewise. (gdb_continue_to_end): Likewise. Add 'command' argument. * lib/cell.exp (skip_cell_tests): Update for exit message change. * gdb.threads/tls.exp: Update for exit message change. * gdb.threads/thread-unwindonsignal.exp: Use gdb_continue_to_end. * gdb.threads/step.exp (step_it): Update for exit message change. (continue_all): Likewise. * gdb.threads/print-threads.exp (test_all_threads): Update for exit message change. * gdb.threads/interrupted-hand-call.exp: Use gdb_continue_to_end. * gdb.threads/execl.exp: Use gdb_continue_to_end. * gdb.python/py-prettyprint.exp (run_lang_tests): Use gdb_continue_to_end. * gdb.hp/gdb.objdbg/objdbg02.exp: Use gdb_continue_to_end. * gdb.hp/gdb.objdbg/objdbg01.exp: Use gdb_continue_to_end. * gdb.hp/gdb.defects/solib-d.exp: Update for exit message change. * gdb.cp/method.exp: Update for exit message change. * gdb.cp/mb-templates.exp: Update for exit message change. * gdb.cp/mb-inline.exp: Use gdb_continue_to_end. * gdb.cp/annota3.exp: Update for exit message change. * gdb.cp/annota2.exp: Update for exit message change. * gdb.cell/fork.exp: Use gdb_continue_to_end. * gdb.base/term.exp: Update for exit message change. * gdb.base/step-test.exp (test_i): Update for exit message change. * gdb.base/sigstep.exp (advance): Update for exit message change. (advancei): Likewise. * gdb.base/siginfo.exp: Update for exit message change. * gdb.base/shlib-call.exp: Use gdb_continue_to_end. * gdb.base/reread.exp: Use gdb_continue_to_end. * gdb.base/langs.exp: Use gdb_continue_to_end. * gdb.base/interrupt.exp: Update for exit message change. * gdb.base/gdb1555.exp: Update for exit message change. * gdb.base/exe-lock.exp: Use gdb_continue_to_end. * gdb.base/ending-run.exp: Update for exit message change. * gdb.base/chng-syms.exp: Update for exit message change. * gdb.base/checkpoint.exp: Update for exit message change. * gdb.base/catch-syscall.exp (check_for_program_end): Use gdb_continue_to_end. (test_catch_syscall_with_wrong_args): Likewise. * gdb.base/call-signal-resume.exp: Use gdb_continue_to_end. * gdb.base/break-interp.exp (test_ld): Update for exit message change. * gdb.base/bang.exp: Update for exit message change. * gdb.base/attach.exp (do_attach_tests): Use gdb_continue_to_end. (do_call_attach_tests): Likewise. * gdb.base/a2-run.exp: Update for exit message change. * gdb.arch/ppc-dfp.exp: Update for exit message change. * gdb.ada/tasks.exp: Use gdb_continue_to_end. * gdb.ada/catch_ex.exp: Use gdb_continue_to_end.
2011-03-07 17:03:04 +01:00
global gdb_prompt inferior_exited_re
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
global clear_done other_handler_location
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
set prefix "$enter_cmd to handler, $in_handler_prefix in handler, $exit_cmd from handler"
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
with_test_prefix $prefix {
restart
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Get us into the handler
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
if { $enter_cmd == "continue" } {
gdb_test "break handler"
} else {
gdb_test "handle SIGALRM print pass stop"
gdb_test "handle SIGVTALRM print pass stop"
gdb_test "continue" "Program received signal.*" "continue to signal"
}
gdb_test "$enter_cmd" ".*handler .*" "$enter_cmd to handler"
delete_breakpoints
uplevel 1 $in_handler
if { $exit_cmd == "continue" } {
gdb_test "break $clear_done" ".*" "break clear done"
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
set test "leave handler"
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
gdb_test_multiple "$exit_cmd" "${test}" {
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
setup_kfail gdb/8841 "sparc*-*-openbsd*"
fail "$test (could not insert single-step breakpoint)"
}
-re "Cannot insert breakpoint.*Cannot access memory.*$gdb_prompt $" {
setup_kfail gdb/8841 "nios2*-*-linux*"
fail "$test (could not insert single-step breakpoint)"
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
-re "done = 1;.*${gdb_prompt} $" {
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
send_gdb "$exit_cmd\n"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
exp_continue -continue_timer
}
-re "\} .. handler .*${gdb_prompt} $" {
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
send_gdb "$exit_cmd\n"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
exp_continue -continue_timer
}
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
setup_kfail gdb/8744 powerpc-*-*bsd*
fail "$test (program exited)"
}
-re "(while ..done|done = 0).*${gdb_prompt} $" {
# After stepping out of a function /r signal-handler, GDB will
# advance the inferior until it is at the first instruction of
# a code-line. While typically things return to the middle of
# the "while..." (and hence GDB advances the inferior to the
# "return..." line) it is also possible for the return to land
# on the first instruction of "while...". Accept both cases.
pass "$test"
}
}
}
}
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
# Map of PREFIX => "things to do within the signal handler", for the
# advance tests.
set in_handler_map {
"nothing" {
}
"si+advance" {
# Advance to the second location in handler.
gdb_test "si" "handler.*" "si in handler"
set test "advance in handler"
gdb_test_multiple "advance $other_handler_location" $test {
-re "Program received signal SIGTRAP.*$gdb_prompt $" {
# On some versions of Linux (observed on
# 3.16.4-200.fc20.x86_64), using PTRACE_SINGLESTEP+sig
# to step into a signal handler, and then issuing
# another PTRACE_SINGLESTEP within the handler ends up
# with $eflags.TF mistakenly set, which results in
# subsequent PTRACE_CONTINUEs trapping after each
# insn.
if {$enter_cmd != "continue"} {
setup_xfail "i?86-*-linux*" gdb/17511
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
setup_xfail "x86_64-*-linux*" gdb/17511
}
fail "$test (spurious SIGTRAP)"
return
}
-re "other handler location.*$gdb_prompt $" {
pass $test
}
}
}
}
# Check that we can step/next/continue, etc. our way in and out of a
# signal handler. Also test that we can step, and run to a breakpoint
# within the handler.
foreach enter_cmd { "stepi" "nexti" "step" "next" "continue" } {
if { $enter_cmd != "continue" && ![can_single_step_to_signal_handler] } {
continue
}
foreach exit_cmd { "step" "next" "continue" } {
foreach {in_handler_prefix in_handler} $in_handler_map {
advance $enter_cmd $in_handler_prefix $in_handler $exit_cmd
}
}
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc advancei { cmd } {
gdb * infrun.c (print_exited_reason): Include inferior id and pid in message. gdb/testsuite * lib/opencl.exp (skip_opencl_tests): Update for exit message change. * lib/mi-support.exp (mi_gdb_test): Update for exit message change. * lib/gdb.exp (gdb_test_multiple): Update comment. Update for exit message change. (skip_altivec_tests): Update for exit message change. (skip_vsx_tests): Likewise. (gdb_continue_to_end): Likewise. Add 'command' argument. * lib/cell.exp (skip_cell_tests): Update for exit message change. * gdb.threads/tls.exp: Update for exit message change. * gdb.threads/thread-unwindonsignal.exp: Use gdb_continue_to_end. * gdb.threads/step.exp (step_it): Update for exit message change. (continue_all): Likewise. * gdb.threads/print-threads.exp (test_all_threads): Update for exit message change. * gdb.threads/interrupted-hand-call.exp: Use gdb_continue_to_end. * gdb.threads/execl.exp: Use gdb_continue_to_end. * gdb.python/py-prettyprint.exp (run_lang_tests): Use gdb_continue_to_end. * gdb.hp/gdb.objdbg/objdbg02.exp: Use gdb_continue_to_end. * gdb.hp/gdb.objdbg/objdbg01.exp: Use gdb_continue_to_end. * gdb.hp/gdb.defects/solib-d.exp: Update for exit message change. * gdb.cp/method.exp: Update for exit message change. * gdb.cp/mb-templates.exp: Update for exit message change. * gdb.cp/mb-inline.exp: Use gdb_continue_to_end. * gdb.cp/annota3.exp: Update for exit message change. * gdb.cp/annota2.exp: Update for exit message change. * gdb.cell/fork.exp: Use gdb_continue_to_end. * gdb.base/term.exp: Update for exit message change. * gdb.base/step-test.exp (test_i): Update for exit message change. * gdb.base/sigstep.exp (advance): Update for exit message change. (advancei): Likewise. * gdb.base/siginfo.exp: Update for exit message change. * gdb.base/shlib-call.exp: Use gdb_continue_to_end. * gdb.base/reread.exp: Use gdb_continue_to_end. * gdb.base/langs.exp: Use gdb_continue_to_end. * gdb.base/interrupt.exp: Update for exit message change. * gdb.base/gdb1555.exp: Update for exit message change. * gdb.base/exe-lock.exp: Use gdb_continue_to_end. * gdb.base/ending-run.exp: Update for exit message change. * gdb.base/chng-syms.exp: Update for exit message change. * gdb.base/checkpoint.exp: Update for exit message change. * gdb.base/catch-syscall.exp (check_for_program_end): Use gdb_continue_to_end. (test_catch_syscall_with_wrong_args): Likewise. * gdb.base/call-signal-resume.exp: Use gdb_continue_to_end. * gdb.base/break-interp.exp (test_ld): Update for exit message change. * gdb.base/bang.exp: Update for exit message change. * gdb.base/attach.exp (do_attach_tests): Use gdb_continue_to_end. (do_call_attach_tests): Likewise. * gdb.base/a2-run.exp: Update for exit message change. * gdb.arch/ppc-dfp.exp: Update for exit message change. * gdb.ada/tasks.exp: Use gdb_continue_to_end. * gdb.ada/catch_ex.exp: Use gdb_continue_to_end.
2011-03-07 17:03:04 +01:00
global gdb_prompt inferior_exited_re
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
with_test_prefix "$cmd from handleri" {
restart
# Get us into the handler.
gdb_test "break handler"
gdb_test "continue" ".* handler .*" "continue to handler"
set program_exited 0
set test "leave handler"
gdb_test_multiple "$cmd" "${test}" {
-re "Cannot insert breakpoint 0.*${gdb_prompt} $" {
# Some platforms use a special read-only page for signal
# trampolines. We can't set a breakpoint there, and we
# don't gracefully fall back to single-stepping.
setup_kfail gdb/8841 "i?86-*-linux*"
setup_kfail gdb/8841 "*-*-openbsd*"
setup_kfail gdb/8841 "nios2-*-linux*"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
fail "$test (could not set breakpoint)"
return
}
-re "Could not insert single-step breakpoint.*$gdb_prompt $" {
setup_kfail gdb/8841 "sparc*-*-openbsd*"
fail "$test (could not insert single-step breakpoint)"
}
-re "Breakpoint \[0-9\]*, handler .*${gdb_prompt} $" {
fail "$test (hit breakpoint again)"
}
-re "done = 1;.*${gdb_prompt} $" {
send_gdb "$cmd\n"
exp_continue -continue_timer
}
-re "\} .. handler .*${gdb_prompt} $" {
send_gdb "$cmd\n"
exp_continue -continue_timer
}
-re "signal handler called.*${gdb_prompt} $" {
pass "$test"
}
-re "main .*${gdb_prompt} $" {
fail "$test (in main)"
}
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
fail "$test (program exited)"
set program_exited 1
}
-re "Make handler return now.*y or n. $" {
send_gdb "y\n"
exp_continue -continue_timer
}
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
set test "leave signal trampoline"
gdb_test_multiple "$cmd" "${test}" {
-re "while .*${gdb_prompt} $" {
pass "$test (in main)"
}
-re "signal handler called.*${gdb_prompt} $" {
send_gdb "$cmd\n"
exp_continue -continue_timer
}
-re "return .*${gdb_prompt} $" {
fail "$test (stepped)"
}
-re "Make .*frame return now.*y or n. $" {
send_gdb "y\n"
exp_continue -continue_timer
}
-re "$inferior_exited_re normally.*${gdb_prompt} $" {
kfail gdb/8744 "$test (program exited)"
set program_exited 1
}
-re "The program is not being run.*${gdb_prompt} $" {
if { $program_exited } {
# Previously kfailed with an exit
pass "$test (the program is not being run)"
} else {
fail "$test (the program is not being run)"
}
}
}
}
}
Test for PR gdb/17511, spurious SIGTRAP after stepping into+in signal handler I noticed that when I single-step into a signal handler with a pending/queued signal, the following single-steps while the program is in the signal handler leave $eflags.TF set. That means subsequent continues will trap after one instruction, resulting in a spurious SIGTRAP being reported to the user. This is a kernel bug; I've reported it to kernel devs (turned out to be a known bug). I'm seeing it on x86_64 Fedora 20 (Linux 3.16.4-200.fc20.x86_64), and I was told it's still not fixed upstream. This commit extends gdb.base/sigstep.exp to cover this use case, xfailed. Here's what the bug looks like: (gdb) start Temporary breakpoint 1, main () at si-handler.c:48 48 setup (); (gdb) next 50 global = 0; /* set break here */ Let's queue a signal, so we can step into the handler: (gdb) handle SIGUSR1 Signal Stop Print Pass to program Description SIGUSR1 Yes Yes Yes User defined signal 1 (gdb) queue-signal SIGUSR1 TF is not set: (gdb) display $eflags 1: $eflags = [ PF ZF IF ] Now step into the handler -- "si" does PTRACE_SINGLESTEP+SIGUSR1: (gdb) si sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF IF ] No TF yet. But another single-step... (gdb) si 0x0000000000400621 31 { 1: $eflags = [ PF ZF TF IF ] ... ends up with TF left set. This results in PTRACE_CONTINUE trapping after each instruction is executed: (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000000400624 in sigusr1_handler (sig=0) at si-handler.c:31 31 { 1: $eflags = [ PF ZF TF IF ] (gdb) c Continuing. Program received signal SIGTRAP, Trace/breakpoint trap. sigusr1_handler (sig=10) at si-handler.c:32 32 global = 0; 1: $eflags = [ PF ZF TF IF ] (gdb) Note that even another PTRACE_SINGLESTEP does not fix it: (gdb) si 33 } 1: $eflags = [ PF ZF TF IF ] (gdb) Eventually, it gets "fixed" by the rt_sigreturn syscall, when returning out of the handler: (gdb) bt #0 sigusr1_handler (sig=10) at si-handler.c:33 #1 <signal handler called> #2 main () at si-handler.c:50 (gdb) set disassemble-next-line on (gdb) si 0x0000000000400632 33 } 0x0000000000400631 <sigusr1_handler+17>: 5d pop %rbp => 0x0000000000400632 <sigusr1_handler+18>: c3 retq 1: $eflags = [ PF ZF TF IF ] (gdb) <signal handler called> => 0x0000003b36a358f0 <__restore_rt+0>: 48 c7 c0 0f 00 00 00 mov $0xf,%rax 1: $eflags = [ PF ZF TF IF ] (gdb) si <signal handler called> => 0x0000003b36a358f7 <__restore_rt+7>: 0f 05 syscall 1: $eflags = [ PF ZF TF IF ] (gdb) main () at si-handler.c:50 50 global = 0; /* set break here */ => 0x000000000040066b <main+9>: c7 05 cb 09 20 00 00 00 00 00 movl $0x0,0x2009cb(%rip) # 0x601040 <global> 1: $eflags = [ PF ZF IF ] (gdb) The bug doesn't happen if we instead PTRACE_CONTINUE into the signal handler -- e.g., set a breakpoint in the handler, queue a signal, and "continue". gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/17511 * gdb.base/sigstep.c (handler): Add a few more writes to 'done'. * gdb.base/sigstep.exp (other_handler_location): New global. (advance): Support stepping into the signal handler, and running commands while in the handler. (in_handler_map): New global. (top level): In the advance test, add combinations for getting into the handler with stepping commands, and for running commands in the handler. Add comment descripting the advancei tests.
2014-10-28 16:51:30 +01:00
# Check that we can step our way out of a signal handler, using
# commands that first step out to the signal trampoline, and then out
# to the mainline code.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
foreach cmd {"stepi" "nexti" "finish" "return"} {
advancei $cmd
}
# Check that we can step/next our way into / over a signal handler.
# There are at least the following cases: breakpoint @pc VS breakpoint
# in handler VS step / next / continue.
# Try stepping when there's a signal pending, and a breakpoint at the
# handler. Should step into the signal handler.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc skip_to_handler { cmd } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
with_test_prefix "$cmd to handler" {
restart
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
# Advance to the infinite loop.
gdb_test "advance $infinite_loop" ".*" "advance to infinite loop"
# Make the signal pending.
sleep 1
# Insert the handler breakpoint.
gdb_test "break handler" ".*" "break handler"
# Step into the handler.
gdb_test "$cmd" " handler .*" "performing $cmd"
}
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
foreach cmd {"step" "next" "continue"} {
skip_to_handler $cmd
}
# Try stepping when there's a signal pending, and a breakpoint at the
# handler's entry-point. Should step into the signal handler stopping
# at the entry-point.
# Some systems (e.x., GNU/Linux as of 2004-08-30), when delivering a
# signal, resume the process at the first instruction of the signal
# handler and not the first instruction of the signal trampoline. The
# stack is constructed such that the signal handler still appears to
# have been called by the trampoline code. This test checks that it
# is possible to stop the inferior, even at that first instruction.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc skip_to_handler_entry { cmd } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
with_test_prefix "$cmd to handler entry" {
restart
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
# Advance to the infinite loop.
gdb_test "advance $infinite_loop" ".*" "advance to infinite loop"
# Make the signal pending.
sleep 1
# Insert / remove the handler breakpoint.
gdb_test "break *handler" ".*" "break handler"
gdb_test "$cmd" " handler .*" "performing $cmd"
}
}
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
skip_to_handler_entry $cmd
}
# Get the address of where a single-step should land.
proc get_next_pc {test} {
global gdb_prompt
global hex
set next ""
gdb_test_multiple "x/2i \$pc" $test {
-re "$hex .*:\[^\r\n\]+\r\n\[ \]+($hex).*\.\r\n$gdb_prompt $" {
set next $expect_out(1,string)
pass $test
}
}
return $next
}
# Test that the command skipped over the handler.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc test_skip_handler {cmd} {
if {$cmd == "stepi" || $cmd == "nexti"} {
set next_pc [get_next_pc "get next PC"]
gdb_test "$cmd" "dummy = 0.*" "performing $cmd"
gdb_test "p /x \$pc" " = $next_pc" "advanced"
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
} else {
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
gdb_test "$cmd" "done = 0.*" "performing $cmd"
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
}
}
# Try stepping when there's a signal pending but no breakpoints.
# Should skip the handler advancing to the next line.
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
proc skip_over_handler { cmd } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
global clear_done
with_test_prefix "$cmd over handler" {
restart
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
gdb_test "break $clear_done" ".*" "break clear done"
# Advance to the infinite loop.
gdb_test "advance $infinite_loop" ".*" "advance to infinite loop"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Make the signal pending.
sleep 1
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
test_skip_handler $cmd
}
}
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
skip_over_handler $cmd
}
# Try stepping when there's a signal pending, a pre-existing
# breakpoint at the current instruction, and a breakpoint in the
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
# handler. Should advance to the signal handler. DISPLACED indicates
# whether to try with or without displaced stepping (to exercise the
# different techniques of stepping over the breakpoint at the current
# instruction).
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
proc breakpoint_to_handler { displaced cmd } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
with_test_prefix "displaced=$displaced: $cmd on breakpoint, to handler" {
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
restart
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
gdb_test_no_output "set displaced-stepping $displaced"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
gdb_test "break $infinite_loop" ".*" "break infinite loop"
gdb_test "break handler" ".*" "break handler"
# Continue to the infinite loop.
gdb_test "continue" "while ..done.*" "continue to infinite loop"
# Make the signal pending.
sleep 1
gdb_test "$cmd" " handler .*" "performing $cmd"
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
# Make sure we the displaced stepping scratch pad isn't in the
# backtrace.
gdb_test_sequence "bt" "backtrace" {
"\[\r\n\]+.0 \[^\r\n\]* handler "
"\[\r\n\]+.1 .signal handler called."
"\[\r\n\]+.2 \[^\r\n\]* main "
}
}
}
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
foreach displaced {"off" "on"} {
foreach cmd {"step" "next" "continue"} {
breakpoint_to_handler $displaced $cmd
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
}
# Try stepping when there's a signal pending, and a breakpoint at the
# handler's entry instruction and a breakpoint at the current
# instruction. Should step into the signal handler and breakpoint at
# that entry instruction.
# Some systems (e.x., GNU/Linux as of 2004-08-30), when delivering a
# signal, resume the process at the first instruction of the signal
# handler and not the first instruction of the signal trampoline. The
# stack is constructed such that the signal handler still appears to
# have been called by the trampoline code. This test checks that it
# is possible to stop the inferior, even at that first instruction.
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
# DISPLACED indicates whether to try with or without displaced
# stepping (to exercise the different techniques of stepping over the
# breakpoint at the current instruction).
proc breakpoint_to_handler_entry { displaced cmd } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
with_test_prefix "displaced=$displaced: $cmd on breakpoint, to handler entry" {
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
restart
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
gdb_test_no_output "set displaced-stepping $displaced"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
gdb_test "break $infinite_loop" ".*" "break infinite loop"
gdb_test "break *handler" ".*" "break handler"
# Continue to the infinite loop.
gdb_test "continue" "while ..done.*" "continue to infinite loop"
# Make the signal pending.
sleep 1
gdb_test "$cmd" " handler .*" "performing $cmd"
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
# Make sure we the displaced stepping scratch pad isn't in the
# backtrace.
gdb_test_sequence "bt" "backtrace" {
"\[\r\n\]+.0 \[^\r\n\]* handler "
"\[\r\n\]+.1 .signal handler called."
"\[\r\n\]+.2 \[^\r\n\]* main "
}
}
}
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
foreach displaced {"off" "on"} {
foreach cmd {"step" "next" "continue"} {
breakpoint_to_handler_entry $displaced $cmd
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
}
# Try stepping when there's a signal pending, and a pre-existing
# breakpoint at the current instruction, and no breakpoint in the
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
# handler. Should advance to the next line/instruction. DISPLACED
# indicates whether to try with or without displaced stepping (to
# exercise the different techniques of stepping over the breakpoint at
# the current instruction). If SW_WATCH is true, set a software
# watchpoint, which exercises stepping the breakpoint instruction
# while delivering a signal at the same time. If NO_HANDLER, arrange
# for the signal's handler be SIG_IGN, thus when the software
# watchpoint is also set, testing stepping a breakpoint instruction
# and immediately triggering the breakpoint (exercises
# adjust_pc_after_break logic).
proc breakpoint_over_handler { displaced cmd with_sw_watch no_handler } {
global infinite_loop
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
global clear_done
PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
2014-10-28 14:42:11 +01:00
set prefix "$cmd on breakpoint, skip handler"
if { $with_sw_watch } {
append prefix ", with sw-watchpoint"
}
if { $no_handler } {
append prefix ", no handler"
}
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
with_test_prefix "displaced=$displaced: $prefix" {
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
restart
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
gdb_test_no_output "set displaced-stepping $displaced"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Use the real-time itimer, as otherwize the process never gets
# enough time to expire the timer.
gdb_test_no_output "set itimer = itimer_real"
PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
2014-10-28 14:42:11 +01:00
if {$no_handler} {
gdb_test "print no_handler = 1" " = 1" \
"set no_handler"
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
gdb_test "break $infinite_loop" ".*" "break infinite loop"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
gdb_test "break $clear_done" ".*" "break clear done"
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
# Continue to the infinite loop
gdb_test "continue" "while ..done.*" "continue to infinite loop"
# Make the signal pending
sleep 1
PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
2014-10-28 14:42:11 +01:00
if { $with_sw_watch } {
# A watchpoint on a convenience variable is always a
# software watchpoint.
gdb_test "watch \$convenience" "Watchpoint .*: \\\$convenience"
}
if {$no_handler} {
# With no handler, we need to set the global ourselves
# manually.
gdb_test "print done = 1" " = 1" "set done"
}
gdb.base/sigstep.exp: cleanup and make it easier to extend Hacking on sigstep.exp, I found it harder to understand and extend than ideal. - GDB is currently not restarted between the different tests/combinations in the file, and some parts of the tests' setup are done on the top level, and shared between tests. It's not trivial to understand which breakpoints each test procedure expects to be set or not set. And it's not trivial to disable parts of the test if you want quickly try out just a subset of the tests (running the whole file takes a bit). - Because GDB is currently not restarted between tests, if some test triggers a ptrace/kernel bug, the following tests may end up with cascading fails. That makes it hard to add a test to cover a kernel bug that isn't fixed yet, with a xfail/kfail. E.g,. note how with kernels with bug gdb/8744 (stepi over sigreturn syscall exits program) the test program exits, and nothing restarts it afterwards... - The manual test message prefix management gets a bit in the way. Nowadays, we have with_test_prefix which makes it simpler. - 'i' is used as parameter name in the various procedures, meaning 'the command the test', which isn't as obvious as it could. This commit addresses all that. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp: Use build_executable instead of prepare_for_testing. (top level): Move code that starts GDB, runs to main and creates a display to ... (restart): ... this new procedure. (top level): Move backtrace from signal handler test to ... (validate_backtrace): ... this new procedure. (advance, advancei): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. (skip_to_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (test_skip_handler): Remove prefix parameter. (skip_over_handler, breakpoint_to_handler) (breakpoint_to_handler_entry, breakpoint_over_handler): Rename parameter from 'i' to 'cmd'. Use with_test_prefix. Always restart GDB. No need to delete breakpoints after the test. (top level): Use foreach to call the test procedures with different commands.
2014-10-28 14:42:10 +01:00
test_skip_handler $cmd
}
}
Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets TL;DR: When stepping over a breakpoint with displaced stepping, the core must be notified of all signals, otherwise the displaced step fixup code confuses a breakpoint trap in the signal handler for the expected trap indicating the displaced instruction was single-stepped normally/successfully. Detailed version: Running sigstep.exp with displaced stepping on, against my x86 software single-step branch, I got: FAIL: gdb.base/sigstep.exp: step on breakpoint, to handler: performing step FAIL: gdb.base/sigstep.exp: next on breakpoint, to handler: performing next FAIL: gdb.base/sigstep.exp: continue on breakpoint, to handler: performing continue Turning on debug logs, we see: (gdb) step infrun: clear_proceed_status_thread (process 32147) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [process 32147] at 0x400842 displaced: stepping process 32147 now displaced: saved 0x400622: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0 displaced: %rip-relative addressing used. displaced: using temp reg 2, old value 0x3615eafd37, new value 0x40084c displaced: copy 0x400842->0x400622: c7 81 1c 08 20 00 00 00 00 00 displaced: displaced pc to 0x400622 displaced: run 0x400622: c7 81 1c 08 LLR: Preparing to resume process 32147, 0, inferior_ptid process 32147 LLR: PTRACE_CONT process 32147, 0 (resume event thread) linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Alarm clock (stopped) LLW: PTRACE_CONT process 32147, Alarm clock (preempt 'handle') LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) sigchld infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 32147, No child processes LLW: waitpid 32147 received Trace/breakpoint trap (stopped) CSBB: process 32147 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 32147. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 32147.32147.0 [process 32147], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED displaced: restored process 32147 0x400622 displaced: fixup (0x400842, 0x400622), insn = 0xc7 0x81 ... displaced: restoring reg 2 to 0x3615eafd37 displaced: relocated %rip from 0x400717 to 0x400937 infrun: stop_pc = 0x400937 infrun: delayed software breakpoint trap, ignoring infrun: no line number info infrun: stop_waiting 0x0000000000400937 in __dso_handle () 1: x/i $pc => 0x400937: and %ah,0xa0d64(%rip) # 0x4a16a1 (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: performing step What should have happened is that the breakpoint hit in the signal handler should have been presented to the user. But note that "preempt 'handle'" -- what happened instead is that displaced_step_fixup confused the breakpoint in the signal handler for the expected SIGTRAP indicating the displaced instruction was single-stepped normally/successfully. This should be affecting all software single-step targets in the same way. The fix is to make sure the core sees all signals when displaced stepping, just like we already must see all signals when doing an stepping over a breakpoint in-line. We now get: infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_ALRM infrun: TARGET_WAITKIND_STOPPED displaced: restored process 570 0x400622 infrun: stop_pc = 0x400842 infrun: random signal (GDB_SIGNAL_ALRM) infrun: signal arrived while stepping over breakpoint infrun: inserting step-resume breakpoint at 0x400842 infrun: resume (step=0, signal=GDB_SIGNAL_ALRM), trap_expected=0, current thread [process 570] at 0x400842 LLR: Preparing to resume process 570, Alarm clock, inferior_ptid process 570 LLR: PTRACE_CONT process 570, Alarm clock (resume event thread) infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 0, No child processes LLW: exit (ignore) infrun: target_wait (-1.0.0, status) = infrun: -1.0.0 [process -1], infrun: status->kind = ignore sigchld infrun: TARGET_WAITKIND_IGNORE infrun: prepare_to_wait linux_nat_wait: [process -1], [TARGET_WNOHANG] LLW: enter LNW: waitpid(-1, ...) returned 570, No child processes LLW: waitpid 570 received Trace/breakpoint trap (stopped) CSBB: process 570 stopped by software breakpoint LNW: waitpid(-1, ...) returned 0, No child processes LLW: trap ptid is process 570. LLW: exit infrun: target_wait (-1.0.0, status) = infrun: 570.570.0 [process 570], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400717 infrun: BPSTAT_WHAT_STOP_NOISY infrun: stop_waiting Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; Hardware single-step targets already behave this way, because the Linux backends (both native and gdbserver) always report signals to the core if the thread was single-stepping. As mentioned in the new comment in do_target_resume, we can't fix this by instead making the displaced_step_fixup phase skip fixing up the PC if the single step stopped somewhere we didn't expect. Here's what the backtrace would look like if we did that: Breakpoint 3, handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 35 done = 1; 1: x/i $pc => 0x400717 <handler+7>: movl $0x1,0x200943(%rip) # 0x601064 <done> (gdb) bt #0 handler (sig=14) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/sigstep.c:35 #1 <signal handler called> #2 0x0000000000400622 in _start () (gdb) FAIL: gdb.base/sigstep.exp: displaced=on: step on breakpoint, to handler: backtrace gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * infrun.c (displaced_step_in_progress): New function. (do_target_resume): Advise target to report all signals if displaced stepping. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.exp (breakpoint_to_handler) (breakpoint_to_handler_entry): New parameter 'displaced'. Use it. Test "backtrace" in handler. (breakpoint_over_handler): New parameter 'displaced'. Use it. (top level): Add new "displaced" test axis to breakpoint_to_handler, breakpoint_to_handler_entry and breakpoint_over_handler.
2015-04-10 11:55:09 +02:00
foreach displaced {"off" "on"} {
foreach cmd {"stepi" "nexti" "step" "next" "continue"} {
foreach with_sw_watch {0 1} {
foreach no_handler {0 1} {
breakpoint_over_handler $displaced $cmd $with_sw_watch $no_handler
}
PR gdb/12623: non-stop crashes inferior, PC adjustment and 1-byte insns TL;DR - if we step an instruction that is as long as decr_pc_after_break (1-byte on x86) right after removing the breakpoint at PC, in non-stop mode, adjust_pc_after_break adjusts the PC, but it shouldn't. In non-stop mode, when a breakpoint is removed, it is moved to the "moribund locations" list. This is because other threads that are running may have tripped on that breakpoint as well, and we haven't heard about it. When a trap is reported, we check if perhaps it was such a deleted breakpoint that caused the trap. If so, we also need to adjust the PC (decr_pc_after_break). Now, say that, on x86: - a breakpoint was placed at an address where we have an instruction of the same length as decr_pc_after_break on this arch (1 on x86). - the breakpoint is removed, and thus put on the moribund locations list. - the thread is single-stepped. As there's no breakpoint inserted at PC anymore, the single-step actually executes the 1-byte instruction normally. GDB should _not_ adjust the PC for the resulting SIGTRAP. But, adjust_pc_after_break confuses the step SIGTRAP reported for this single-step as being a SIGTRAP for the moribund location of the breakpoint that used to be at the previous PC, and so infrun applies the decr_pc_after_break adjustment incorrectly. The confusion comes from the special case mentioned in the comment: static void adjust_pc_after_break (struct execution_control_state *ecs) { ... As a special case, we could have hardware single-stepped a software breakpoint. In this case (prev_pc == breakpoint_pc), we also need to back up to the breakpoint address. */ if (thread_has_single_step_breakpoints_set (ecs->event_thread) || !ptid_equal (ecs->ptid, inferior_ptid) || !currently_stepping (ecs->event_thread) || (ecs->event_thread->stepped_breakpoint && ecs->event_thread->prev_pc == breakpoint_pc)) regcache_write_pc (regcache, breakpoint_pc); The condition that incorrectly triggers is the "ecs->event_thread->prev_pc == breakpoint_pc" one. Afterwards, the next resume resume re-executes an instruction that had already executed, which if you're lucky, results in the inferior crashing. If you're unlucky, you'll get silent bad behavior... The fix is to remember that we stepped a breakpoint. Turns out the only case we step a breakpoint instruction today isn't covered by the testsuite. It's the case of a 'handle nostop" signal arriving while a step is in progress _and_ we have a software watchpoint, which forces always single-stepping. This commit extends sigstep.exp to cover that, and adds a new test for the adjust_pc_after_break issue. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdbthread.h (struct thread_info) <stepped_breakpoint>: New field. * infrun.c (resume) <stepping breakpoint instruction>: Set the thread's stepped_breakpoint field. Skip if reverse debugging. Add comment. (init_thread_stepping_state, handle_signal_stop): Clear the thread's stepped_breakpoint field. gdb/testsuite/ 2014-10-28 Pedro Alves <palves@redhat.com> PR gdb/12623 * gdb.base/sigstep.c (no_handler): New global. (main): If 'no_handler is true, set the signal handlers to SIG_IGN. * gdb.base/sigstep.exp (breakpoint_over_handler): Add with_sw_watch and no_handler parameters. Handle them. (top level) <stepping over handler when stopped at a breakpoint test>: Add a test axis for testing with a software watchpoint, and another for testing with the signal handler set to SIG_IGN. * gdb.base/step-sw-breakpoint-adjust-pc.c: New file. * gdb.base/step-sw-breakpoint-adjust-pc.exp: New file.
2014-10-28 14:42:11 +01:00
}
}
stepi/nexti: skip signal handler if "handle nostop" signal arrives I noticed that "si" behaves differently when a "handle nostop" signal arrives while the step is in progress, depending on whether the program was stopped at a breakpoint when "si" was entered. Specifically, in case GDB needs to step off a breakpoint, the handler is skipped and the program stops in the next "mainline" instruction. Otherwise, the "si" stops in the first instruction of the signal handler. I was surprised the testsuite doesn't catch this difference. Turns out gdb.base/sigstep.exp covers a bunch of cases related to stepping and signal handlers, but does not test stepi nor nexti, only step/next/continue. My first reaction was that stopping in the signal handler was the correct thing to do, as it's where the next user-visible instruction that is executed is. I considered then "nexti" -- a signal handler could be reasonably considered a subroutine call to step over, it'd seem intuitive to me that "nexti" would skip it. But then, I realized that signals that arrive while a plain/line "step" is in progress _also_ have their handler skipped. A user might well be excused for being confused by this, given: (gdb) help step Step program until it reaches a different source line. And the signal handler's sources will be in different source lines, after all. I think that having to explain that "stepi" steps into handlers, (and that "nexti" wouldn't according to my reasoning above), while "step" does not, is a sign of an awkward interface. E.g., if a user truly is interested in stepping into signal handlers, then it's odd that she has to either force the signal to "handle stop", or recall to do "stepi" whenever such a signal might be delivered. For that use case, it'd seem nicer to me if "step" also stepped into handlers. This suggests to me that we either need a global "step-into-handlers" setting, or perhaps better, make "handle pass/nopass stop/nostop print/noprint" have have an additional axis - "handle stepinto/nostepinto", so that the user could configure whether handlers for specific signals should be stepped into. In any case, I think it's simpler (and thus better) for all step commands to behave the same. This commit thus makes "si/ni" skip handlers for "handle nostop" signals that arrive while the command was already in progress, like step/next do. To be clear, nothing changes if the program was stopped for a signal, and the user enters a stepping command _then_ -- GDB still steps into the handler. The change concerns signals that don't cause a stop and that arrive while the step is in progress. Tested on x86_64 Fedora 20, native and gdbserver. gdb/ 2014-10-27 Pedro Alves <palves@redhat.com> * infrun.c (handle_signal_stop): Also skip handlers when a random signal arrives while handling a "stepi" or a "nexti". Set the thread's 'step_after_step_resume_breakpoint' flag. gdb/doc/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.texinfo (Continuing and Stepping): Add cross reference to info on stepping and signal handlers. (Signals): Explain stepping and signal handlers. Add context index entry, and cross references. gdb/testsuite/ 2014-10-27 Pedro Alves <palves@redhat.com> * gdb.base/sigstep.c (dummy): New global. (main): Issue a couple writes to the new global. * gdb.base/sigstep.exp (get_next_pc, test_skip_handler): New procedures. (skip_over_handler): Use test_skip_handler. (top level): Call skip_over_handler for stepi and nexti too. (breakpoint_over_handler): Use test_skip_handler. (top level): Call breakpoint_over_handler for stepi and nexti too.
2014-10-27 21:24:59 +01:00
}