This is the mail archive of the gdb@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]

Re: Why does "target remote" to a non-stop target stop one thread


I can't answer your question, but I once asked a similar one, see http://sourceware.org/ml/gdb/2010-12/msg00048.html

I still think that this is a GDB bug. I therefore use a patch like this:

@@ -2669,8 +2669,11 @@ notice_new_inferior (ptid_t ptid, int leave_running, int from_tty)
       /* We're going to install breakpoints, and poke at memory,
      ensure that the inferior is stopped for a moment while we do
      that.  */
-      target_stop (inferior_ptid);
-
+      /* But not if the target should be kept running - which
+     is the case for all Indel target during attach... */
+      if( !leave_running ) {
+          target_stop (inferior_ptid);
+      }
       inferior->control.stop_soon = STOP_QUIETLY_REMOTE;

       /* Wait for stop before proceeding.  */

On 06/27/2013 10:38 PM, Jeremy Bennett wrote:
I'm working on GDB for a remote target, using non-stop mode.

When I connect to the target, even in non-stop mode, it insists on
stopping one thread. The comment in notice_new_inferior () is:

       /* We're going to install breakpoints, and poke at memory,
	 ensure that the inferior is stopped for a moment while we do
	 that.  */
My question is, why we need to stop any thread. Surely the whole point
of non-stop mode is that we don't generally want to stop any threads if
it can be avoided.

I'd appreciate understanding the thinking behind this, before I start
suggesting patches to change the behavior.

Thanks,


Jeremy



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