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

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

[Jeremy Bennett]

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

-- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeId: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com
Twitter: @embecosm

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

[Raphael Zulliger]

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
>

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

[Yao Qi]

On 06/28/2013 04:38 AM, Jeremy Bennett wrote:
> hen 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.

Hi Jeremy,
AFAIK, "non-stop" means when GDB is examining one stopped thread while 
other threads are _not stopped_.

See 
http://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode

GDB needs the thread stopped because ptrace can't be performed on the 
running thread.

-- 
Yao (齐尧)

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

[Jeremy Bennett]

On 28/06/13 10:14, Yao Qi wrote:
> On 06/28/2013 04:38 AM, Jeremy Bennett wrote:
>> hen 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.
> 
> Hi Jeremy,
> AFAIK, "non-stop" means when GDB is examining one stopped thread while
> other threads are _not stopped_.
> 
> See
> http://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode
> 
> 
> GDB needs the thread stopped because ptrace can't be performed on the
> running thread.
> 
Hi Yao,

Thanks for the explanation. Since I am working on a RTOS that does not
use ptrace, and can perform actions on running threads, I don't need to
stop. So it looks like something like the patch suggested by Raphael
Zulliger that makes this configurable depending on the target would be a
useful.

I'll work on this.


Jeremy

-- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeId: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com
Twitter: @embecosm

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

[Luis Machado]

On 06/28/2013 10:06 AM, Jeremy Bennett wrote:
> On 28/06/13 10:14, Yao Qi wrote:
>> On 06/28/2013 04:38 AM, Jeremy Bennett wrote:
>>> hen 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.
>>
>> Hi Jeremy,
>> AFAIK, "non-stop" means when GDB is examining one stopped thread while
>> other threads are _not stopped_.
>>
>> See
>> http://sourceware.org/gdb/onlinedocs/gdb/Non_002dStop-Mode.html#Non_002dStop-Mode
>>
>>
>> GDB needs the thread stopped because ptrace can't be performed on the
>> running thread.
>>
> Hi Yao,
>
> Thanks for the explanation. Since I am working on a RTOS that does not
> use ptrace, and can perform actions on running threads, I don't need to
> stop. So it looks like something like the patch suggested by Raphael
> Zulliger that makes this configurable depending on the target would be a
> useful.
>
> I'll work on this.
>
>
> Jeremy
>

Does "set may-interrupt off" help any?

Luis