Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [patch] Fix handle_inferior_event nostop signal handling for threads
@ 2004-03-07  1:06 Daniel Jacobowitz
  2004-03-07 14:14 ` Atsushi Nemoto
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-07  1:06 UTC (permalink / raw)
  To: gdb-patches; +Cc: Atsushi Nemoto

Atsushi-san, could you verify that this patch still fixes your problem?
I took a look at the #if 0 block, and that made me look at the surrounding
code; I don't believe that a bit of it is necessary.  If we switch "current"
threads in response to this event, then all the following bits of
handle_inferior_event should handle the current thread correctly.

If this works for you I'll commit it to HEAD.  I'm not sure if it's safe for
the branch.  No regressions on native i686-linux, and it fixes a quirk that
the previous patch I sent you introduced (we could sometimes fail to print
about a pass/print/nostop signal).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-03-06  Daniel Jacobowitz  <drow@mvista.com>

	* infrun.c (handle_inferior_event): Remove short-circuit code for
	events in a different thread.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.138
diff -u -p -r1.138 infrun.c
--- infrun.c	6 Mar 2004 00:10:06 -0000	1.138
+++ infrun.c	7 Mar 2004 00:31:51 -0000
@@ -1883,61 +1883,9 @@ handle_inferior_event (struct execution_
     ecs->random_signal = 1;
 
   /* See if something interesting happened to the non-current thread.  If
-     so, then switch to that thread, and eventually give control back to
-     the user.
-
-     Note that if there's any kind of pending follow (i.e., of a fork,
-     vfork or exec), we don't want to do this now.  Rather, we'll let
-     the next resume handle it. */
-  if (!ptid_equal (ecs->ptid, inferior_ptid) &&
-      (pending_follow.kind == TARGET_WAITKIND_SPURIOUS))
+     so, then switch to that thread.  */
+  if (!ptid_equal (ecs->ptid, inferior_ptid))
     {
-      int printed = 0;
-
-      /* If it's a random signal for a non-current thread, notify user
-         if he's expressed an interest. */
-      if (ecs->random_signal && signal_print[stop_signal])
-	{
-/* ??rehrauer: I don't understand the rationale for this code.  If the
-   inferior will stop as a result of this signal, then the act of handling
-   the stop ought to print a message that's couches the stoppage in user
-   terms, e.g., "Stopped for breakpoint/watchpoint".  If the inferior
-   won't stop as a result of the signal -- i.e., if the signal is merely
-   a side-effect of something GDB's doing "under the covers" for the
-   user, such as stepping threads over a breakpoint they shouldn't stop
-   for -- then the message seems to be a serious annoyance at best.
-
-   For now, remove the message altogether. */
-#if 0
-	  printed = 1;
-	  target_terminal_ours_for_output ();
-	  printf_filtered ("\nProgram received signal %s, %s.\n",
-			   target_signal_to_name (stop_signal),
-			   target_signal_to_string (stop_signal));
-	  gdb_flush (gdb_stdout);
-#endif
-	}
-
-      /* If it's not SIGTRAP and not a signal we want to stop for, then
-         continue the thread. */
-
-      if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
-	{
-	  if (printed)
-	    target_terminal_inferior ();
-
-	  /* Clear the signal if it should not be passed.  */
-	  if (signal_program[stop_signal] == 0)
-	    stop_signal = TARGET_SIGNAL_0;
-
-	  target_resume (ecs->ptid, 0, stop_signal);
-	  prepare_to_wait (ecs);
-	  return;
-	}
-
-      /* It's a SIGTRAP or a signal we're interested in.  Switch threads,
-         and fall into the rest of wait_for_inferior().  */
-
       context_switch (ecs);
 
       if (context_hook)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-07  1:06 [patch] Fix handle_inferior_event nostop signal handling for threads Daniel Jacobowitz
@ 2004-03-07 14:14 ` Atsushi Nemoto
  2004-03-19  0:09   ` Atsushi Nemoto
  2004-03-09 16:41 ` Daniel Jacobowitz
  2004-03-19  0:09 ` Daniel Jacobowitz
  2 siblings, 1 reply; 10+ messages in thread
From: Atsushi Nemoto @ 2004-03-07 14:14 UTC (permalink / raw)
  To: drow; +Cc: gdb-patches

>>>>> On Sat, 6 Mar 2004 20:06:54 -0500, Daniel Jacobowitz <drow@false.org> said:

drow> Atsushi-san, could you verify that this patch still fixes your
drow> problem?
...
drow> If this works for you I'll commit it to HEAD.  I'm not sure if
drow> it's safe for the branch.  No regressions on native i686-linux,
drow> and it fixes a quirk that the previous patch I sent you
drow> introduced (we could sometimes fail to print about a
drow> pass/print/nostop signal).

Thank you, it's OK for me.  I also had found that the quirk and now it
seems to be fixed also.

---
Atsushi Nemoto


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-07  1:06 [patch] Fix handle_inferior_event nostop signal handling for threads Daniel Jacobowitz
  2004-03-07 14:14 ` Atsushi Nemoto
@ 2004-03-09 16:41 ` Daniel Jacobowitz
  2004-03-10  1:28   ` Atsushi Nemoto
  2004-03-19  0:09   ` Daniel Jacobowitz
  2004-03-19  0:09 ` Daniel Jacobowitz
  2 siblings, 2 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-09 16:41 UTC (permalink / raw)
  To: gdb-patches; +Cc: Atsushi Nemoto

On Sat, Mar 06, 2004 at 08:06:54PM -0500, Daniel Jacobowitz wrote:
> Atsushi-san, could you verify that this patch still fixes your problem?
> I took a look at the #if 0 block, and that made me look at the surrounding
> code; I don't believe that a bit of it is necessary.  If we switch "current"
> threads in response to this event, then all the following bits of
> handle_inferior_event should handle the current thread correctly.
> 
> If this works for you I'll commit it to HEAD.  I'm not sure if it's safe for
> the branch.  No regressions on native i686-linux, and it fixes a quirk that
> the previous patch I sent you introduced (we could sometimes fail to print
> about a pass/print/nostop signal).

> 2004-03-06  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* infrun.c (handle_inferior_event): Remove short-circuit code for
> 	events in a different thread.

I've committed this for HEAD after retesting on i686-linux and
i686-linux/gdbserver.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-09 16:41 ` Daniel Jacobowitz
@ 2004-03-10  1:28   ` Atsushi Nemoto
  2004-03-19  0:09     ` Atsushi Nemoto
  2004-03-19  0:09     ` Daniel Jacobowitz
  2004-03-19  0:09   ` Daniel Jacobowitz
  1 sibling, 2 replies; 10+ messages in thread
From: Atsushi Nemoto @ 2004-03-10  1:28 UTC (permalink / raw)
  To: drow; +Cc: gdb-patches

>>>>> On Tue, 9 Mar 2004 11:41:00 -0500, Daniel Jacobowitz <drow@false.org> said:
drow> I've committed this for HEAD after retesting on i686-linux and
drow> i686-linux/gdbserver.

Thanks!  I'm more happy if I see the fix in 6.1 branch too.  Is it too
late for 6.1 release ?

---
Atsushi Nemoto


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-19  0:09     ` Daniel Jacobowitz
@ 2004-03-10  2:57       ` Daniel Jacobowitz
  0 siblings, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-10  2:57 UTC (permalink / raw)
  To: Atsushi Nemoto; +Cc: gdb-patches

On Wed, Mar 10, 2004 at 10:29:20AM +0900, Atsushi Nemoto wrote:
> >>>>> On Tue, 9 Mar 2004 11:41:00 -0500, Daniel Jacobowitz <drow@false.org> said:
> drow> I've committed this for HEAD after retesting on i686-linux and
> drow> i686-linux/gdbserver.
> 
> Thanks!  I'm more happy if I see the fix in 6.1 branch too.  Is it too
> late for 6.1 release ?

I'd prefer not to - infrun is infamously fragile.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-07 14:14 ` Atsushi Nemoto
@ 2004-03-19  0:09   ` Atsushi Nemoto
  0 siblings, 0 replies; 10+ messages in thread
From: Atsushi Nemoto @ 2004-03-19  0:09 UTC (permalink / raw)
  To: drow; +Cc: gdb-patches

>>>>> On Sat, 6 Mar 2004 20:06:54 -0500, Daniel Jacobowitz <drow@false.org> said:

drow> Atsushi-san, could you verify that this patch still fixes your
drow> problem?
...
drow> If this works for you I'll commit it to HEAD.  I'm not sure if
drow> it's safe for the branch.  No regressions on native i686-linux,
drow> and it fixes a quirk that the previous patch I sent you
drow> introduced (we could sometimes fail to print about a
drow> pass/print/nostop signal).

Thank you, it's OK for me.  I also had found that the quirk and now it
seems to be fixed also.

---
Atsushi Nemoto


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-09 16:41 ` Daniel Jacobowitz
  2004-03-10  1:28   ` Atsushi Nemoto
@ 2004-03-19  0:09   ` Daniel Jacobowitz
  1 sibling, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19  0:09 UTC (permalink / raw)
  To: gdb-patches; +Cc: Atsushi Nemoto

On Sat, Mar 06, 2004 at 08:06:54PM -0500, Daniel Jacobowitz wrote:
> Atsushi-san, could you verify that this patch still fixes your problem?
> I took a look at the #if 0 block, and that made me look at the surrounding
> code; I don't believe that a bit of it is necessary.  If we switch "current"
> threads in response to this event, then all the following bits of
> handle_inferior_event should handle the current thread correctly.
> 
> If this works for you I'll commit it to HEAD.  I'm not sure if it's safe for
> the branch.  No regressions on native i686-linux, and it fixes a quirk that
> the previous patch I sent you introduced (we could sometimes fail to print
> about a pass/print/nostop signal).

> 2004-03-06  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* infrun.c (handle_inferior_event): Remove short-circuit code for
> 	events in a different thread.

I've committed this for HEAD after retesting on i686-linux and
i686-linux/gdbserver.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 10+ messages in thread

* [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-07  1:06 [patch] Fix handle_inferior_event nostop signal handling for threads Daniel Jacobowitz
  2004-03-07 14:14 ` Atsushi Nemoto
  2004-03-09 16:41 ` Daniel Jacobowitz
@ 2004-03-19  0:09 ` Daniel Jacobowitz
  2 siblings, 0 replies; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19  0:09 UTC (permalink / raw)
  To: gdb-patches; +Cc: Atsushi Nemoto

Atsushi-san, could you verify that this patch still fixes your problem?
I took a look at the #if 0 block, and that made me look at the surrounding
code; I don't believe that a bit of it is necessary.  If we switch "current"
threads in response to this event, then all the following bits of
handle_inferior_event should handle the current thread correctly.

If this works for you I'll commit it to HEAD.  I'm not sure if it's safe for
the branch.  No regressions on native i686-linux, and it fixes a quirk that
the previous patch I sent you introduced (we could sometimes fail to print
about a pass/print/nostop signal).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2004-03-06  Daniel Jacobowitz  <drow@mvista.com>

	* infrun.c (handle_inferior_event): Remove short-circuit code for
	events in a different thread.

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.138
diff -u -p -r1.138 infrun.c
--- infrun.c	6 Mar 2004 00:10:06 -0000	1.138
+++ infrun.c	7 Mar 2004 00:31:51 -0000
@@ -1883,61 +1883,9 @@ handle_inferior_event (struct execution_
     ecs->random_signal = 1;
 
   /* See if something interesting happened to the non-current thread.  If
-     so, then switch to that thread, and eventually give control back to
-     the user.
-
-     Note that if there's any kind of pending follow (i.e., of a fork,
-     vfork or exec), we don't want to do this now.  Rather, we'll let
-     the next resume handle it. */
-  if (!ptid_equal (ecs->ptid, inferior_ptid) &&
-      (pending_follow.kind == TARGET_WAITKIND_SPURIOUS))
+     so, then switch to that thread.  */
+  if (!ptid_equal (ecs->ptid, inferior_ptid))
     {
-      int printed = 0;
-
-      /* If it's a random signal for a non-current thread, notify user
-         if he's expressed an interest. */
-      if (ecs->random_signal && signal_print[stop_signal])
-	{
-/* ??rehrauer: I don't understand the rationale for this code.  If the
-   inferior will stop as a result of this signal, then the act of handling
-   the stop ought to print a message that's couches the stoppage in user
-   terms, e.g., "Stopped for breakpoint/watchpoint".  If the inferior
-   won't stop as a result of the signal -- i.e., if the signal is merely
-   a side-effect of something GDB's doing "under the covers" for the
-   user, such as stepping threads over a breakpoint they shouldn't stop
-   for -- then the message seems to be a serious annoyance at best.
-
-   For now, remove the message altogether. */
-#if 0
-	  printed = 1;
-	  target_terminal_ours_for_output ();
-	  printf_filtered ("\nProgram received signal %s, %s.\n",
-			   target_signal_to_name (stop_signal),
-			   target_signal_to_string (stop_signal));
-	  gdb_flush (gdb_stdout);
-#endif
-	}
-
-      /* If it's not SIGTRAP and not a signal we want to stop for, then
-         continue the thread. */
-
-      if (stop_signal != TARGET_SIGNAL_TRAP && !signal_stop[stop_signal])
-	{
-	  if (printed)
-	    target_terminal_inferior ();
-
-	  /* Clear the signal if it should not be passed.  */
-	  if (signal_program[stop_signal] == 0)
-	    stop_signal = TARGET_SIGNAL_0;
-
-	  target_resume (ecs->ptid, 0, stop_signal);
-	  prepare_to_wait (ecs);
-	  return;
-	}
-
-      /* It's a SIGTRAP or a signal we're interested in.  Switch threads,
-         and fall into the rest of wait_for_inferior().  */
-
       context_switch (ecs);
 
       if (context_hook)


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-10  1:28   ` Atsushi Nemoto
@ 2004-03-19  0:09     ` Atsushi Nemoto
  2004-03-19  0:09     ` Daniel Jacobowitz
  1 sibling, 0 replies; 10+ messages in thread
From: Atsushi Nemoto @ 2004-03-19  0:09 UTC (permalink / raw)
  To: drow; +Cc: gdb-patches

>>>>> On Tue, 9 Mar 2004 11:41:00 -0500, Daniel Jacobowitz <drow@false.org> said:
drow> I've committed this for HEAD after retesting on i686-linux and
drow> i686-linux/gdbserver.

Thanks!  I'm more happy if I see the fix in 6.1 branch too.  Is it too
late for 6.1 release ?

---
Atsushi Nemoto


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [patch] Fix handle_inferior_event nostop signal handling for threads
  2004-03-10  1:28   ` Atsushi Nemoto
  2004-03-19  0:09     ` Atsushi Nemoto
@ 2004-03-19  0:09     ` Daniel Jacobowitz
  2004-03-10  2:57       ` Daniel Jacobowitz
  1 sibling, 1 reply; 10+ messages in thread
From: Daniel Jacobowitz @ 2004-03-19  0:09 UTC (permalink / raw)
  To: Atsushi Nemoto; +Cc: gdb-patches

On Wed, Mar 10, 2004 at 10:29:20AM +0900, Atsushi Nemoto wrote:
> >>>>> On Tue, 9 Mar 2004 11:41:00 -0500, Daniel Jacobowitz <drow@false.org> said:
> drow> I've committed this for HEAD after retesting on i686-linux and
> drow> i686-linux/gdbserver.
> 
> Thanks!  I'm more happy if I see the fix in 6.1 branch too.  Is it too
> late for 6.1 release ?

I'd prefer not to - infrun is infamously fragile.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-03-10  2:57 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-07  1:06 [patch] Fix handle_inferior_event nostop signal handling for threads Daniel Jacobowitz
2004-03-07 14:14 ` Atsushi Nemoto
2004-03-19  0:09   ` Atsushi Nemoto
2004-03-09 16:41 ` Daniel Jacobowitz
2004-03-10  1:28   ` Atsushi Nemoto
2004-03-19  0:09     ` Atsushi Nemoto
2004-03-19  0:09     ` Daniel Jacobowitz
2004-03-10  2:57       ` Daniel Jacobowitz
2004-03-19  0:09   ` Daniel Jacobowitz
2004-03-19  0:09 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox