Go to file
Pedro Alves 8f572e5c0f 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 10:55:09 +01:00
bfd Downgrade linker error on protected symbols in .dynbss to a warning 2015-04-10 19:16:47 +09:30
binutils Properly check --compress-debug-sections=XXX 2015-04-09 10:56:28 -07:00
config
cpu
elfcpp Add chdr_size, Chdr, Chdr_write and Chdr_data 2015-04-08 10:29:40 -07:00
etc
gas Add documentation about the interation of the ARM assembler's -EB option and the linker's --be8 option. 2015-04-10 08:26:07 +01:00
gdb Fix gdb.base/sigstep.exp with displaced stepping on software single-step targets 2015-04-10 10:55:09 +01:00
gold Allow gold to resolve defined TLS symbols in a PIE link. 2015-04-09 15:47:37 -07:00
gprof
include Add support to the RX toolchain to restrict the use of string instructions. 2015-04-09 12:48:37 +01:00
intl
ld Revert "Add extern_protected_data and set it for x86" 2015-04-10 19:16:47 +09:30
libdecnumber
libiberty
opcodes
readline
sim
texinfo
zlib
.cvsignore
.gitattributes
.gitignore
ChangeLog
compile
config-ml.in
config.guess
config.rpath
config.sub
configure
configure.ac
COPYING
COPYING3
COPYING3.LIB
COPYING.LIB
COPYING.LIBGLOSS
COPYING.NEWLIB
depcomp
djunpack.bat
install-sh
libtool.m4
lt~obsolete.m4
ltgcc.m4
ltmain.sh
ltoptions.m4
ltsugar.m4
ltversion.m4
MAINTAINERS
Makefile.def
Makefile.in
Makefile.tpl
makefile.vms
missing
mkdep
mkinstalldirs
move-if-change
README
README-maintainer-mode
setup.com
src-release.sh
symlink-tree
ylwrap

		   README for GNU development tools

This directory contains various GNU compilers, assemblers, linkers, 
debuggers, etc., plus their support routines, definitions, and documentation.

If you are receiving this as part of a GDB release, see the file gdb/README.
If with a binutils release, see binutils/README;  if with a libg++ release,
see libg++/README, etc.  That'll give you info about this
package -- supported targets, how to use it, how to report bugs, etc.

It is now possible to automatically configure and build a variety of
tools with one command.  To build all of the tools contained herein,
run the ``configure'' script here, e.g.:

	./configure 
	make

To install them (by default in /usr/local/bin, /usr/local/lib, etc),
then do:
	make install

(If the configure script can't determine your type of computer, give it
the name as an argument, for instance ``./configure sun4''.  You can
use the script ``config.sub'' to test whether a name is recognized; if
it is, config.sub translates it to a triplet specifying CPU, vendor,
and OS.)

If you have more than one compiler on your system, it is often best to
explicitly set CC in the environment before running configure, and to
also set CC when running make.  For example (assuming sh/bash/ksh):

	CC=gcc ./configure
	make

A similar example using csh:

	setenv CC gcc
	./configure
	make

Much of the code and documentation enclosed is copyright by
the Free Software Foundation, Inc.  See the file COPYING or
COPYING.LIB in the various directories, for a description of the
GNU General Public License terms under which you can copy the files.

REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info
on where and how to report problems.