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] |
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] |