Re: [PATCH][fix for gdb/15853] 'thread apply all inetrrupt&' shows inefficiency on remote targets

[Pedro Alves <palves at redhat dot com>]

On 08/28/2013 10:09 AM, Yao Qi wrote:
> On 08/27/2013 10:00 PM, Muhammad Bilal wrote:
>> In the case of 'interrupt -a&' command gdb sends only one packet to
>> stop all  threads as $vCont;t#b9...
> 
> Here is the doc on "interrupt -a",
> 
> interrupt
> interrupt -a
> Suspend execution of the running program. In all-stop mode, interrupt
> stops the whole process, but in non-stop mode, it stops only the
> current thread. To stop the whole program in non-stop mode, use
> interrupt -a.
> 
> The "whole program" is ambiguous in multi-process debugging.  IMO, 
> "whole program" means the process.  That is to say, "interrupt -a" only 
> applies to the threads in the process.  Threads in other processes are 
> not affected.  However, that is not true.  I tried "interrupt -a" in a
> multi-inferior of multi-thread program, it stops *all* threads in *all*
> inferiors.

Yeah.  IIRC, we taught GDB about non-stop before multi-inferior, and
when the latter was added, those bits of the docs weren't adjusted.
"-a" means all threads of all processes, everything.

> The comments are clear,
> 
> /* Stop the execution of the target while running in async mode, in
>     the backgound.  In all-stop, stop the whole process.  In non-stop
>     mode, stop the current thread only by default, or stop all threads
>     if the `-a' switch is used.  */
> 
> /* interrupt [-a]  */
> static void
> interrupt_target_command (char *args, int from_tty)
> 
> What is the expect scope of "interrupt -a"? current process or all 
> processes?

All processes.

>> But in case of 'thread apply all interrupt&' GDB issues individual
>> packet for each thread.I think that In non-stop mode
>> 'interrupt -a&' and 'thread apply all interrupt&' commands are equals
>> but time efficiency of later command is less.
>>
>> Also,
>>
>> If user issues a command like 'thread apply all interrupt -a&'
>> GDB accepts it and GDB will stop all threads on first vcount;t packets
>> but due to loops iteration on all threads,
>> GDB sends vcount;t packet for all remaining threads although GDB has
>> already stop all thread so IMO it is a bug.
> 
> It is less efficient, but not a bug me.  Optimization to this special 
> case looks not good to me.  It adds extra complexities, but the gain is 
> limited AFAICS.

Agreed.

> IMO, the real program here is that we need ITSET to describe a
> set of arbitrary processes and thread to the remote target through
> protocol.
> 
>    $vCont;t:[t7786-7788] // stop thread 7786 to thread 7788.

Not clear to me at this point how the protocol should exactly look
like, but agreed in principle.

-- 
Pedro Alves