This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] gdb.reverse/sigall-precsave.exp: cope with software single-step.


gdb.reverse/sigall-precsave.exp has a bunch of failures with software
single-step targets.  The test program generates a bunch of signals,
and has handlers for all of those installed.  The test first runs the
program through all those signals and handlers, recording the
execution log, and then dumps the record to a core, and restarts a new
debug session with that record log, to test the record/core target.
In the part that tests debugging the record log, the test sets
breakpoints at the signal handlers, and expects them to hit (given the
program has indeed executed them when it was recorded, that's
reasonable).

But recall that:

- the record target logs execution by forcing the target to
  single-step all the way, even when the target is supposed to be
  continued.

- On software single-step targets, there's no way to single-step into
  a signal handler.  GDB puts a breakpoint at the instruction it
  thinks the PC will point at after the current instruction, but it
  has no clue where/which address will a signal handler execute from,
  or if any will run at all.  So a single-step while delivering a
  signal on sss targets skips the whole signal handler, IOW, signal
  handlers are transparent to GDB on sss targets.  On hardware step
  targets, a single-step while delivering a signal, like
  PTRACE_STEP/signo, will magically step into the first instruction of
  the handler of $signo.

- So when the test expects expects breakpoints at handlers to work
  when replaying the recorded execution log, they don't, because GDB
  never single-stepped into the handlers when the execution was being
  recorded in the first place.

Then one fix is just to set breakpoints at all the handlers' entry
points while recording, so that later replaying can stop there.
That's what this patch does.  Another approach would be to skip the
test on SSS targets, but after this patch, the test exposes yet
another problem, so it is worth it to keep it working on such targets
too.

Tested on x86_64 Fedora 17 {hardware,software} single-step.

Applied.

2012-07-19  Pedro Alves  <palves@redhat.com>

	* gdb.reverse/sigall-precsave.exp: Set a breakpoint at each signal
	handler before recording.
---
 gdb/testsuite/gdb.reverse/sigall-precsave.exp |   27 ++++++++++++++++++++++++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.reverse/sigall-precsave.exp b/gdb/testsuite/gdb.reverse/sigall-precsave.exp
index e2dabf9..ee3240b 100644
--- a/gdb/testsuite/gdb.reverse/sigall-precsave.exp
+++ b/gdb/testsuite/gdb.reverse/sigall-precsave.exp
@@ -254,7 +254,32 @@ set signals {
     TERM
 }
 
-gdb_test "continue" "Breakpoint .* end of main .*" "run to end of main"
+# Software single-step targets can't step into signal handlers.  Since
+# later, when replaying the execution log, the test wants to set
+# breakpoints on handlers, we need to make sure that while recording,
+# GDB steps through the handlers too, so that the execution log covers
+# them.  Setting breakpoints in all handlers takes care of it.  This
+# is harmless for hardware-step targets.
+foreach sig $signals {
+    set test "break *handle_$sig"
+    gdb_test_multiple $test $test {
+	-re "Breakpoint .*$gdb_prompt $" {
+	    # No need to record a pass for each breakpoint.
+	}
+    }
+}
+
+gdb_test_multiple "continue" "continue" {
+    -re "Breakpoint .* end of main .*$gdb_prompt $" {
+	pass "run to end of main"
+    }
+    -re "Breakpoint .* handle_.*$gdb_prompt $" {
+	send_gdb "continue\n"
+	exp_continue
+    }
+}
+
+delete_breakpoints
 
 gdb_test "record save $precsave" \
     "Saved core file $precsave with execution log\."  \


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]