This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[patch/rfc] Simplify step-over-signal, fix XFAIL: next to 2nd alarm(1) (probably kernel bug)
- From: Andrew Cagney <cagney at gnu dot org>
- To: gdb-patches at sources dot redhat dot com
- Date: Sun, 09 May 2004 15:48:40 -0400
- Subject: [patch/rfc] Simplify step-over-signal, fix XFAIL: next to 2nd alarm(1) (probably kernel bug)
Hello,
The attached greatly simplifies how GDB handles ``step-over-signal'' and
in the process fixes what the comments refer to as a `kernel bug' (the
bug is still there but its effect is not seen).
The old code was trying to implement step-over-signal the same way that
GDB steps over a function - step into the signal (i.e., deliver it) and
then, as an after thought, set a special breakpoint at the signal's
return address. That way, when the signal handler returns to the
step/next range, the inferior will again stop. Unfortunately, the
inferior may not stop after signal delivery, or may stop in the signal
handler instead of sigtramp, and consequently the breakpoint may never
be set. The code tried to work around this by calling check_sigtramp2
at every and any opportunity :-(
The attached patch instead inserts the breakpoint _before_ signal
delivery (while the PC is still in the single-step range). Further,
instead of a dedicated signal breakpoint, it just uses the existing
step-over-function's step_resume_breakpoint (you can't be both stepping
over a function and a signal).
As for the kernel bug (ref gdb/1639), since the inferior now always gets
a sigtrap from the step resume breakpoint, the single-step bit never
gets the chance to cause problems. Consequently I've updated
signals.exp (but left the comments for reference).
On NetBSD/PPC (which has a kernel problem) this fixes:
FAIL: gdb.base/signals.exp: backtrace in signals_tests_1
FAIL: gdb.base/signals.exp: continue to func1
XFAIL: gdb.base/signals.exp: continue to handler
FAIL: gdb.base/signals.exp: next to 2nd ++count in signals_tests_1
FAIL: gdb.base/signals.exp: next to 2nd alarm
FAIL: gdb.base/signals.exp: next to handler in signals_tests_1
while on GNU/Linux it fixes:
XFAIL: gdb.base/signals.exp: continue to handler
baring comments I'll commit in a day or so,
Andrew
PS: I'll garbage collect the now unused signal breakpoint variable as a
separate patch.
Index: ChangeLog
2004-05-08 Andrew Cagney <cagney@redhat.com>
* infrun.c (check_sigtramp2): Delete function.
(handle_inferior_event): When single stepping, and taking a
signal, set a breakpoint at the signal return address. Delete
redundant calls to check_sigtramp2.
(insert_step_resume_breakpoint): New function.
(through_sigtramp_breakpoint, handle_inferior_event)
(follow_exec, wait_for_inferior, fetch_inferior_event)
(currently_stepping, keep_going): Delete most uses of
through_sigtramp_breakpoint, not that it should be deleted.
(delete_breakpoint_current_contents): Delete function.
Index: testsuite/ChangeLog
2004-05-09 Andrew Cagney <cagney@redhat.com>
* gdb.base/signals.exp (signal_tests_1): Simplify "continue to
func1" and "next to 2nd alarm", kernel bug avoided.
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.152
diff -p -u -r1.152 infrun.c
--- infrun.c 8 May 2004 22:26:09 -0000 1.152
+++ infrun.c 9 May 2004 18:41:59 -0000
@@ -60,8 +60,6 @@ static void resume_cleanups (void *);
static int hook_stop_stub (void *);
-static void delete_breakpoint_current_contents (void *);
-
static int restore_selected_frame (void *);
static void build_infrun (void);
@@ -305,6 +303,8 @@ static int breakpoints_failed;
static int stop_print_frame;
static struct breakpoint *step_resume_breakpoint = NULL;
+/* NOTE: cagney/2004-05-08: This variable needs to be garbage
+ collected, it isn't used. */
static struct breakpoint *through_sigtramp_breakpoint = NULL;
/* On some platforms (e.g., HP-UX), hardware watchpoints have bad
@@ -423,9 +423,6 @@ follow_exec (int pid, char *execd_pathna
step_range_start = 0;
step_range_end = 0;
- /* If there was one, it's gone now. */
- through_sigtramp_breakpoint = NULL;
-
/* What is this a.out's name? */
printf_unfiltered ("Executing new program: %s\n", execd_pathname);
@@ -905,17 +902,6 @@ init_wait_for_inferior (void)
stepping_past_singlestep_breakpoint = 0;
}
-
-static void
-delete_breakpoint_current_contents (void *arg)
-{
- struct breakpoint **breakpointp = (struct breakpoint **) arg;
- if (*breakpointp != NULL)
- {
- delete_breakpoint (*breakpointp);
- *breakpointp = NULL;
- }
-}
/* This enum encodes possible reasons for doing a target_wait, so that
wfi can call target_wait in one place. (Ultimately the call will be
@@ -984,9 +970,10 @@ void init_execution_control_state (struc
static void handle_step_into_function (struct execution_control_state *ecs);
void handle_inferior_event (struct execution_control_state *ecs);
-static void check_sigtramp2 (struct execution_control_state *ecs);
static void step_into_function (struct execution_control_state *ecs);
static void step_over_function (struct execution_control_state *ecs);
+static void insert_step_resume_breakpoint (struct frame_info *step_frame,
+ struct execution_control_state *ecs);
static void stop_stepping (struct execution_control_state *ecs);
static void prepare_to_wait (struct execution_control_state *ecs);
static void keep_going (struct execution_control_state *ecs);
@@ -1008,8 +995,6 @@ wait_for_inferior (void)
old_cleanups = make_cleanup (delete_step_resume_breakpoint,
&step_resume_breakpoint);
- make_cleanup (delete_breakpoint_current_contents,
- &through_sigtramp_breakpoint);
/* wfi still stays in a loop, so it's OK just to take the address of
a local to get the ecs pointer. */
@@ -1070,8 +1055,6 @@ fetch_inferior_event (void *client_data)
{
old_cleanups = make_exec_cleanup (delete_step_resume_breakpoint,
&step_resume_breakpoint);
- make_exec_cleanup (delete_breakpoint_current_contents,
- &through_sigtramp_breakpoint);
/* Fill in with reasonable starting values. */
init_execution_control_state (async_ecs);
@@ -1989,15 +1972,9 @@ handle_inferior_event (struct execution_
return;
}
- /* Don't even think about breakpoints
- if just proceeded over a breakpoint.
-
- However, if we are trying to proceed over a breakpoint
- and end up in sigtramp, then through_sigtramp_breakpoint
- will be set and we should check whether we've hit the
- step breakpoint. */
- if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected
- && through_sigtramp_breakpoint == NULL)
+ /* Don't even think about breakpoints if just proceeded over a
+ breakpoint. */
+ if (stop_signal == TARGET_SIGNAL_TRAP && trap_expected)
bpstat_clear (&stop_bpstat);
else
{
@@ -2080,39 +2057,22 @@ process_event_stop_test:
if (signal_program[stop_signal] == 0)
stop_signal = TARGET_SIGNAL_0;
- /* I'm not sure whether this needs to be check_sigtramp2 or
- whether it could/should be keep_going.
-
- This used to jump to step_over_function if we are stepping,
- which is wrong.
-
- Suppose the user does a `next' over a function call, and while
- that call is in progress, the inferior receives a signal for
- which GDB does not stop (i.e., signal_stop[SIG] is false). In
- that case, when we reach this point, there is already a
- step-resume breakpoint established, right where it should be:
- immediately after the function call the user is "next"-ing
- over. If we call step_over_function now, two bad things
- happen:
-
- - we'll create a new breakpoint, at wherever the current
- frame's return address happens to be. That could be
- anywhere, depending on what function call happens to be on
- the top of the stack at that point. Point is, it's probably
- not where we need it.
-
- - the existing step-resume breakpoint (which is at the correct
- address) will get orphaned: step_resume_breakpoint will point
- to the new breakpoint, and the old step-resume breakpoint
- will never be cleaned up.
-
- The old behavior was meant to help HP-UX single-step out of
- sigtramps. It would place the new breakpoint at prev_pc, which
- was certainly wrong. I don't know the details there, so fixing
- this probably breaks that. As with anything else, it's up to
- the HP-UX maintainer to furnish a fix that doesn't break other
- platforms. --JimB, 20 May 1999 */
- check_sigtramp2 (ecs);
+ if (step_range_end != 0
+ && stop_signal != TARGET_SIGNAL_0
+ && stop_pc >= step_range_start && stop_pc < step_range_end
+ && frame_id_eq (get_frame_id (get_current_frame ()), step_frame_id))
+ {
+ /* The inferior is about to take a signal that will take it
+ out of the single step range. Set a breakpoint at the
+ current PC (which is presumably where the signal handler
+ will eventually return) and then allow the inferior to
+ run free.
+
+ Note that this is only needed for a signal delivered
+ while in the single-step range. Nested signals aren't a
+ problem as they eventually all return. */
+ insert_step_resume_breakpoint (get_current_frame (), ecs);
+ }
keep_going (ecs);
return;
}
@@ -2153,13 +2113,6 @@ process_event_stop_test:
{
delete_step_resume_breakpoint (&step_resume_breakpoint);
}
- /* Not sure whether we need to blow this away too, but probably
- it is like the step-resume breakpoint. */
- if (through_sigtramp_breakpoint != NULL)
- {
- delete_breakpoint (through_sigtramp_breakpoint);
- through_sigtramp_breakpoint = NULL;
- }
#if 0
/* FIXME - Need to implement nested temporary breakpoints */
@@ -2207,9 +2160,8 @@ process_event_stop_test:
case BPSTAT_WHAT_STOP_NOISY:
stop_print_frame = 1;
- /* We are about to nuke the step_resume_breakpoint and
- through_sigtramp_breakpoint via the cleanup chain, so
- no need to worry about it here. */
+ /* We are about to nuke the step_resume_breakpointt via the
+ cleanup chain, so no need to worry about it here. */
stop_stepping (ecs);
return;
@@ -2217,9 +2169,8 @@ process_event_stop_test:
case BPSTAT_WHAT_STOP_SILENT:
stop_print_frame = 0;
- /* We are about to nuke the step_resume_breakpoint and
- through_sigtramp_breakpoint via the cleanup chain, so
- no need to worry about it here. */
+ /* We are about to nuke the step_resume_breakpoin via the
+ cleanup chain, so no need to worry about it here. */
stop_stepping (ecs);
return;
@@ -2251,10 +2202,6 @@ process_event_stop_test:
break;
case BPSTAT_WHAT_THROUGH_SIGTRAMP:
- if (through_sigtramp_breakpoint)
- delete_breakpoint (through_sigtramp_breakpoint);
- through_sigtramp_breakpoint = NULL;
-
/* If were waiting for a trap, hitting the step_resume_break
doesn't count as getting it. */
if (trap_expected)
@@ -2398,9 +2345,6 @@ process_event_stop_test:
/* Having a step-resume breakpoint overrides anything
else having to do with stepping commands until
that breakpoint is reached. */
- /* I'm not sure whether this needs to be check_sigtramp2 or
- whether it could/should be keep_going. */
- check_sigtramp2 (ecs);
keep_going (ecs);
return;
}
@@ -2408,9 +2352,6 @@ process_event_stop_test:
if (step_range_end == 0)
{
/* Likewise if we aren't even stepping. */
- /* I'm not sure whether this needs to be check_sigtramp2 or
- whether it could/should be keep_going. */
- check_sigtramp2 (ecs);
keep_going (ecs);
return;
}
@@ -2422,9 +2363,6 @@ process_event_stop_test:
within it! */
if (stop_pc >= step_range_start && stop_pc < step_range_end)
{
- /* We might be doing a BPSTAT_WHAT_SINGLE and getting a signal.
- So definately need to check for sigtramp here. */
- check_sigtramp2 (ecs);
keep_going (ecs);
return;
}
@@ -2688,50 +2626,13 @@ process_event_stop_test:
static int
currently_stepping (struct execution_control_state *ecs)
{
- return ((through_sigtramp_breakpoint == NULL
- && !ecs->handling_longjmp
+ return ((!ecs->handling_longjmp
&& ((step_range_end && step_resume_breakpoint == NULL)
|| trap_expected))
|| ecs->stepping_through_solib_after_catch
|| bpstat_should_step ());
}
-static void
-check_sigtramp2 (struct execution_control_state *ecs)
-{
- char *name;
- struct symtab_and_line sr_sal;
-
- /* Check that what has happened here is that we have just stepped
- the inferior with a signal (because it is a signal which
- shouldn't make us stop), thus stepping into sigtramp. */
-
- if (!trap_expected)
- return;
- if (get_frame_type (get_current_frame ()) != SIGTRAMP_FRAME)
- return;
-
- /* So we need to set a step_resume_break_address breakpoint and
- continue until we hit it, and then step. FIXME: This should be
- more enduring than a step_resume breakpoint; we should know that
- we will later need to keep going rather than re-hitting the
- breakpoint here (see the testsuite, gdb.base/signals.exp where it
- says "exceedingly difficult"). */
-
- init_sal (&sr_sal); /* initialize to zeroes */
- sr_sal.pc = prev_pc;
- sr_sal.section = find_pc_overlay (sr_sal.pc);
- /* We perhaps could set the frame if we kept track of what the frame
- corresponding to prev_pc was. But we don't, so don't. */
- through_sigtramp_breakpoint =
- set_momentary_breakpoint (sr_sal, null_frame_id, bp_through_sigtramp);
- if (breakpoints_inserted)
- insert_breakpoints ();
-
- ecs->remove_breakpoints_on_following_step = 1;
- ecs->another_trap = 1;
-}
-
/* Subroutine call with source code we should not step over. Do step
to the first line of code in it. */
@@ -2809,6 +2710,38 @@ step_into_function (struct execution_con
keep_going (ecs);
}
+/* The inferior, as a result of a function call (has left) or signal
+ (about to leave) the single-step range. Set a momentary breakpoint
+ within the step range where the inferior is expected to later
+ return. */
+
+static void
+insert_step_resume_breakpoint (struct frame_info *step_frame,
+ struct execution_control_state *ecs)
+{
+ struct symtab_and_line sr_sal;
+
+ /* This is only used within the step-resume range/frame. */
+ gdb_assert (frame_id_eq (step_frame_id, get_frame_id (step_frame)));
+ gdb_assert (step_range_end != 0);
+ gdb_assert (get_frame_pc (step_frame) >= step_range_start
+ && get_frame_pc (step_frame) < step_range_end);
+
+ init_sal (&sr_sal); /* initialize to zeros */
+
+ sr_sal.pc = ADDR_BITS_REMOVE (get_frame_pc (step_frame));
+ sr_sal.section = find_pc_overlay (sr_sal.pc);
+
+ check_for_old_step_resume_breakpoint ();
+
+ step_resume_breakpoint
+ = set_momentary_breakpoint (sr_sal, get_frame_id (step_frame),
+ bp_step_resume);
+
+ if (breakpoints_inserted)
+ insert_breakpoints ();
+}
+
/* We've just entered a callee, and we wish to resume until it returns
to the caller. Setting a step_resume breakpoint on the return
address will catch a return from the callee.
@@ -2933,15 +2866,13 @@ keep_going (struct execution_control_sta
/* If we've just finished a special step resume and we don't
want to hit a breakpoint, pull em out. */
if (step_resume_breakpoint == NULL
- && through_sigtramp_breakpoint == NULL
&& ecs->remove_breakpoints_on_following_step)
{
ecs->remove_breakpoints_on_following_step = 0;
remove_breakpoints ();
breakpoints_inserted = 0;
}
- else if (!breakpoints_inserted &&
- (through_sigtramp_breakpoint != NULL || !ecs->another_trap))
+ else if (!breakpoints_inserted && !ecs->another_trap)
{
breakpoints_failed = insert_breakpoints ();
if (breakpoints_failed)
Index: testsuite/gdb.base/signals.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.base/signals.exp,v
retrieving revision 1.5
diff -p -u -r1.5 signals.exp
--- testsuite/gdb.base/signals.exp 8 Jun 2003 13:02:58 -0000 1.5
+++ testsuite/gdb.base/signals.exp 9 May 2004 18:42:05 -0000
@@ -60,102 +60,47 @@ proc signal_tests_1 {} {
# An alarm has been signaled, give the signal time to get delivered.
sleep 2
- # i386 BSD currently fails the next test with a SIGTRAP.
- setup_xfail "i*86-*-bsd*"
- # But Dynix has a DECR_PC_AFTER_BREAK of zero, so the failure
- # is shadowed by hitting the through_sigtramp_breakpoint.
- clear_xfail "i*86-sequent-bsd*"
- # Univel SVR4 i386 continues instead of stepping.
- setup_xfail "i*86-univel-sysv4*"
- # lynx fails with "next" acting like "continue"
- setup_xfail "*-*-*lynx*"
- # linux (aout versions) also fails with "next" acting like "continue"
- # this is probably more dependant on the kernel version than on the
- # object file format or utils. (sigh)
- setup_xfail "i*86-pc-linuxaout-gnu" "i*86-pc-linuxoldld-gnu"
- send_gdb "next\n"
- gdb_expect {
- -re "alarm .*$gdb_prompt $" { pass "next to 2nd alarm (1)" }
- -re "Program received signal SIGTRAP.*first.*$gdb_prompt $" {
-
- # This can happen on machines that have a trace flag
- # in their PS register.
- # The trace flag in the PS register will be set due to
- # the `next' command.
- # Before calling the signal handler, the PS register
- # is pushed along with the context on the user stack.
- # When the signal handler has finished, it reenters the
- # the kernel via a sigreturn syscall, which restores the
- # PS register along with the context.
- # If the kernel erroneously does not clear the trace flag
- # in the pushed context, gdb will receive a SIGTRAP from
- # the set trace flag in the restored context after the
- # signal handler has finished.
-
- # I do not yet understand why the SIGTRAP does not occur
- # after stepping the instruction at the restored PC on
- # i386 BSDI 1.0 systems.
-
- # Note that the vax under Ultrix also exhibits
- # this behaviour (it is uncovered by the `continue from
- # a break in a signal handler' test below).
- # With this test the failure is shadowed by hitting the
- # through_sigtramp_breakpoint upon return from the signal
- # handler.
-
- # SVR4 and Linux based i*86 systems exhibit this behaviour
- # as well (it is uncovered by the `continue from a break
- # in a signal handler' test below).
- # As these systems use procfs, where we tell the kernel not
- # to tell gdb about `pass' signals, and the trace flag is
- # cleared by the kernel before entering the sigtramp
- # routine, GDB will not notice the execution of the signal
- # handler.
- # Upon return from the signal handler, GDB will receive
- # a SIGTRAP from the set trace flag in the restored context.
- # The SIGTRAP marks the end of a (albeit long winded)
- # single step for GDB, causing this test to pass.
+ # NOTE: cagney/2004-05-09: The following is retained as an
+ # historical reference. Because signal delivery when doing a
+ # next has been changed to use a continue, and not a
+ # single-step, the kernel bug of a stuck trace-bit in the
+ # trampoline's saved PS register is avoided.
+
+ # This can happen on machines that have a trace flag in their
+ # PS register. The trace flag in the PS register will be set
+ # due to the `next' command. Before calling the signal
+ # handler, the PS register is pushed along with the context on
+ # the user stack. When the signal handler has finished, it
+ # reenters the the kernel via a sigreturn syscall, which
+ # restores the PS register along with the context. If the
+ # kernel erroneously does not clear the trace flag in the
+ # pushed context, gdb will receive a SIGTRAP from the set
+ # trace flag in the restored context after the signal handler
+ # has finished.
+
+ # I do not yet understand why the SIGTRAP does not occur after
+ # stepping the instruction at the restored PC on i386 BSDI 1.0
+ # systems.
+
+ # Note that the vax under Ultrix also exhibits this behaviour
+ # (it is uncovered by the `continue from a break in a signal
+ # handler' test below). With this test the failure is
+ # shadowed by hitting the through_sigtramp_breakpoint upon
+ # return from the signal handler.
+
+ # SVR4 and Linux based i*86 systems exhibit this behaviour as
+ # well (it is uncovered by the `continue from a break in a
+ # signal handler' test below). As these systems use procfs,
+ # where we tell the kernel not to tell gdb about `pass'
+ # signals, and the trace flag is cleared by the kernel before
+ # entering the sigtramp routine, GDB will not notice the
+ # execution of the signal handler. Upon return from the
+ # signal handler, GDB will receive a SIGTRAP from the set
+ # trace flag in the restored context. The SIGTRAP marks the
+ # end of a (albeit long winded) single step for GDB, causing
+ # this test to pass.
- fail "next to 2nd alarm (1) (probably kernel bug)"
- gdb_test "next" "alarm.*" "next to 2nd alarm (1)"
- }
- -re "Program exited with code.*$gdb_prompt $" {
-
- # This is apparently a bug in the UnixWare kernel (but
- # has not been investigated beyond the
- # resume/target_wait level, and has not been reported
- # to Univel). If it steps when a signal is pending,
- # it does a continue instead. I don't know whether
- # there is a workaround.
-
- # Perhaps this problem exists on other SVR4 systems;
- # but (a) we have no reason to think so, and (b) if we
- # put a wrong xfail here, we never get an XPASS to let
- # us know that it was incorrect (and then if such a
- # configuration regresses we have no way of knowing).
- # Solaris is not a relevant data point either way
- # because it lacks single stepping.
-
- # fnf: I don't agree with the above philosophy. We
- # can never be sure that any particular XFAIL is
- # specified 100% correctly in that no systems with
- # the bug are missed and all systems without the bug
- # are excluded. If we include an XFAIL that isn't
- # appropriate for a particular system, then when that
- # system gets tested it will XPASS, and someone should
- # investigate and fix the setup_xfail as appropriate,
- # or more preferably, the actual bug. Each such case
- # adds more data to narrowing down the scope of the
- # problem and ultimately fixing it.
-
- setup_xfail "i*86-*-sysv4*"
- fail "'next' behaved as 'continue (known SVR4 bug)'"
- return 0
- }
- -re ".*$gdb_prompt $" { fail "next to 2nd alarm (1)" }
- timeout { fail "next to 2nd alarm (1); (timeout)" }
- eof { fail "next to 2nd alarm (1); (eof)" }
- }
+ gdb_test "next" "alarm .*" "next to 2nd alarm"
gdb_test "break handler" "Breakpoint \[0-9\]+ .*"
gdb_test "next" "\\+\\+count; /\\* second \\*/" \
@@ -191,41 +136,13 @@ proc signal_tests_1 {} {
gdb_test "break func1" "Breakpoint \[0-9\]+ .*"
gdb_test "break func2" "Breakpoint \[0-9\]+ .*"
- # Vax Ultrix and i386 BSD currently fail the next test with
- # a SIGTRAP, but with different symptoms.
- setup_xfail "vax-*-ultrix*"
- setup_xfail "i*86-*-bsd*"
- setup_xfail "i*86-*-freebsd*"
- setup_xfail "i*86-pc-linux-gnu*"
- setup_xfail "i*86-*-solaris2*"
- send_gdb "continue\n"
- gdb_expect {
- -re "Breakpoint.*func1.*$gdb_prompt $" { pass "continue to func1" }
- -re "Program received signal SIGTRAP.*second.*$gdb_prompt $" {
-
- # See explanation for `next to 2nd alarm (1)' fail above.
- # We did step into the signal handler, hit a breakpoint
- # in the handler and continued from the breakpoint.
- # The set trace flag in the restored context is causing
- # the SIGTRAP, without stepping an instruction.
-
- fail "continue to func1 (probably kernel bug)"
- gdb_test "continue" "Breakpoint.*func1.*" \
- "extra continue to func1"
- }
- -re "Program received signal SIGTRAP.*func1 ..;.*$gdb_prompt $" {
+ # NOTE: cagney/2004-05-09: Ref "next to 2nd alarm" above.
+ # Because signal delivery when doing a next has been changed
+ # to use a continue, and not a single-step, the kernel bug of
+ # a stuck trace-bit in the trampoline's saved PS register is
+ # avoided.
- # On the vax under Ultrix the set trace flag in the restored
- # context is causing the SIGTRAP, but after stepping one
- # instruction, as expected.
-
- fail "continue to func1 (probably kernel bug)"
- gdb_test "continue" "Breakpoint.*func1.*" \
- "extra continue to func1"
- }
- -re ".*$gdb_prompt $" { fail "continue to func1" }
- default { fail "continue to func1" }
- }
+ gdb_test "continue" "Breakpoint.*func1.*" "continue to func1"
setup_xfail "*-*-irix*"
send_gdb "signal SIGUSR1\n"