Add test for PR18214 and PR18216 - multiple step-overs with queued signals

Both PRs are triggered by the same use case.

PR18214 is about software single-step targets.  On those, the 'resume'
code that detects that we're stepping over a breakpoint and delivering
a signal at the same time:

  /* Currently, our software single-step implementation leads to different
     results than hardware single-stepping in one situation: when stepping
     into delivering a signal which has an associated signal handler,
     hardware single-step will stop at the first instruction of the handler,
     while software single-step will simply skip execution of the handler.
...
     Fortunately, we can at least fix this particular issue.  We detect
     here the case where we are about to deliver a signal while software
     single-stepping with breakpoints removed.  In this situation, we
     revert the decisions to remove all breakpoints and insert single-
     step breakpoints, and instead we install a step-resume breakpoint
     at the current address, deliver the signal without stepping, and
     once we arrive back at the step-resume breakpoint, actually step
     over the breakpoint we originally wanted to step over.  */

doesn't handle the case of _another_ thread also needing to step over
a breakpoint.  Because the other thread is just resumed at the PC
where it had stopped and a breakpoint is still inserted there, the
thread immediately re-traps the same breakpoint.  This test exercises
that.  On software single-step targets, it fails like this:

 KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler
 KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2: continue to sigusr1_handler

gdb.log (simplified):

 (gdb) continue
 Continuing.

 Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
 66            callme (); /* set breakpoint thread 2 here */
 (gdb) thread 3
 (gdb) queue-signal SIGUSR1
 (gdb) thread 1
 [Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))]
 #0  main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106
 106       wait_threads (); /* set wait-threads breakpoint here */
 (gdb) break sigusr1_handler
 Breakpoint 5 at 0x400837: file src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31.
 (gdb) continue
 Continuing.
 [Switching to Thread 0x7ffff7fc0700 (LWP 24828)]

 Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66
 66            callme (); /* set breakpoint thread 2 here */
 (gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler


For good measure, I made the test try displaced stepping too.  And
then I found it crashes GDB on x86-64 (a hardware step target), but
only when displaced stepping... :

 KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler (PRMS: gdb/18216)
 KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2: continue to sigusr1_handler (PRMS: gdb/18216)
 KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3: continue to sigusr1_handler (PRMS: gdb/18216)

 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
 4964          if (sr_bp->loc->permanent
 Setting up the environment for debugging gdb.
 Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54.
 Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217.
 (top-gdb) p sr_bp
 $1 = (struct breakpoint *) 0x0
 (top-gdb) bt
 #0  0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
 #1  0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715
 #2  0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165
 #3  0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298
 #4  0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
 #5  0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658
 #6  0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0, ready_mask=1) at src/gdb/event-loop.c:658

The all-stop-non-stop series fixes this, but meanwhile, this augments
the multiple-step-overs.exp test to cover this, KFAILed.

gdb/testsuite/ChangeLog:
2015-04-08  Pedro Alves  <palves@redhat.com>

	PR gdb/18214
	PR gdb/18216
	* gdb.threads/multiple-step-overs.c (sigusr1_handler): New
	function.
	(main): Install it as SIGUSR1 handler.
	* gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix'
	parameter.  Always use "setup" as prefix.  Toggle "set
	displaced-stepping" off/on depending on global.  Don't switch to
	thread 1 here.
	(top level): Add displaced stepping "off/on" test axis.  Update
	"setup" calls.  Wrap each subtest with with_test_prefix.  Test
	continuing with a queued signal in each thread.

0 files changed, 0 insertions, 0 deletions