I don't know that that's the whole story. According to the gdb-remote protocol specs, the async packet (%Stop) may be sent at any time. So I would expect that if, after you got the OK response to the vStopped query, another running thread stopped or crashed you would get another %Stop packet.
The docs describing this are here: https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html and the notification packet page: https://sourceware.org/gdb/current/onlinedocs/gdb/Notification-Packets.html#Notification-Packets I could be misreading their intent? Anyway, it looks like Ewan's patches only changed the GDBRemote handling layer (except for adding the non-stop target property.) I would be very surprised if non-stop mode could really be supported with no equivalent changes in the upper layers, since I know I make the assumption that stop means all stop in a bunch of places. I tried not to do this in a way I couldn't back out of when the time came to do non-stop mode, but I was explicitly NOT trying to support non-stop mode. I don't think it would be a huge chunk of work to finish this up, but I would be really really surprised if it was no work. I could not find any indication of tests for the non-stop-mode, so even if it worked at some point, it's becomes less and less trustworthy as time goes on... Jim > On Feb 3, 2017, at 11:53 AM, Ted Woodward <ted.woodw...@codeaurora.org> wrote: > > I think the remote stub only sends extra stop replies in response to a > vStopped packet. Here is a stop for 2 threads hitting a common breakpoint: > > < 51> send packet: $vCont;c:10b6;c:10f8;c:00b3;c:00b2;c:00b1;c:00b0#e0 > < 1> read packet: + > < 6> read packet: $OK#9a > < 1> send packet: + > < 58> read packet: %Stop:T052a:c8f4f5e0;1e:90de101b;1d:48dd101b;thread:af;#1d > < 1> send packet: + > < 12> send packet: $vStopped#55 > < 1> read packet: + > < 53> read packet: $T052a:c8f4f5e0;1e:309c101b;1d:e89a101b;thread:b0;#d8 > < 1> send packet: + > < 12> send packet: $vStopped#55 > < 1> read packet: + > < 6> read packet: $OK#9a > > So we won't get any spurious stops in the middle of processing. > > "Experimental feature, not tested" is noted - I'll mention that in my meeting > today. > > -- > Qualcomm Innovation Center, Inc. > The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a > Linux Foundation Collaborative Project > > >> -----Original Message----- >> From: jing...@apple.com [mailto:jing...@apple.com] >> Sent: Friday, February 03, 2017 1:22 PM >> To: Ted Woodward <ted.woodw...@codeaurora.org> >> Cc: Greg Clayton <gclay...@apple.com>; LLDB <lldb-dev@lists.llvm.org> >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi? >> >> >>> On Feb 3, 2017, at 10:51 AM, Ted Woodward >> <ted.woodw...@codeaurora.org> wrote: >>> >>> I'm working on plumbing the existing non-stop mode switch (target.non- >> stop-mode) to lldb-mi, to give Eclipse access to non-stop mode. >>> >>> The remote OS is very thread-heavy, and the remote stub doesn't limit the >> debugger to the current process - because there isn't one, from the stub's >> point of view. Just a collection of threads. In all-stop mode, if a 2nd >> thread >> hits a breakpoint, it will send back a 2nd stop reply, which confuses lldb >> (rightly so). In non-stop mode, it handles things correctly. So we'll just >> have >> to live with the possible missed breakpoint issue. >> >> We tried to keep the possibility of a non-stop mode in mind when designing >> lldb, but I know there are places in lldb at present that assume that if you >> get >> a "stop" event you won't get another stop event till lldb issues a run. We >> try >> not to fall over completely if we get events we don't expect, but we're more >> likely to just discard them than do the right thing. There also don't >> appear to >> be any tests running programs in non-stop mode and exercising their >> behavior, so any extent to which it works will be accidental and unstable. >> >> Seems like this is an experimental feature at best, and should be marked as >> such. >> >> Jim >> >>> >>> -- >>> Qualcomm Innovation Center, Inc. >>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, >>> a Linux Foundation Collaborative Project >>> >>> >>>> -----Original Message----- >>>> From: jing...@apple.com [mailto:jing...@apple.com] >>>> Sent: Friday, February 03, 2017 10:58 AM >>>> To: Greg Clayton <gclay...@apple.com> >>>> Cc: Ted Woodward <ted.woodw...@codeaurora.org>; LLDB <lldb- >>>> d...@lists.llvm.org> >>>> Subject: Re: [lldb-dev] non-stop mode with lldb-mi? >>>> >>>> >>>>> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev <lldb- >>>> d...@lists.llvm.org> wrote: >>>>> >>>>> Non-stop mode is a huge change to the core of LLDB isn’t it. I think >>>>> you >>>> might think this is easier than it actually is to enable in LLDB? >>>>> >>>>> Is non-stop mode where you can leave some threads running while >>>>> others >>>> are stopped? The biggest issue with this is to do it right we need to >>>> be able to emulate instructions so that if 3 threads hit breakpoints, >>>> we would need to emulate the instruction that used to be at the >>>> breakpoint in LLDB since we can’t remove the breakpoint (unless you >>>> stop the other threads which defeats the purpose of non-stop mode) >>>> without the other 2 threads possibly missing the breakpoint while you >>>> disable breakpoint, single step, enable breakpoint. >>>> >>>> That is just one of the many things that will have to be changed to >>>> support non-stop mode. For now, non-stop mode is only likely to work >>>> reliably if the threads you are allowing to run never stop - hit >>>> breakpoints, crash or whatever - so worrying about missing breakpoints is >> a second order problem. >>>> >>>> Anyway, even as it is it has some utility - presumably you're using >>>> it because you have some threads in your program that can't stop, so >>>> you're not likely to want them to hit breakpoints anyway... But the >>>> current help text for the non-stop setting should probably include some >> appropriate caveats. >>>> >>>> Jim >>>> >>>> >>>>> >>>>> Greg >>>>> >>>>>> On Feb 3, 2017, at 7:54 AM, Ted Woodward via lldb-dev <lldb- >>>> d...@lists.llvm.org> wrote: >>>>>> >>>>>> That turns on and off async, but not non-stop. >>>>>> >>>>>> I’m working on adding support for –gdb-set and –gdb-show non-stop, >>>> and will post my changes on phabricator when I’m done. >>>>>> >>>>>> -- >>>>>> Qualcomm Innovation Center, Inc. >>>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora >>>> Forum, a Linux Foundation Collaborative Project >>>>>> >>>>>> From: Ilia K [mailto:ki.s...@gmail.com] >>>>>> Sent: Wednesday, February 01, 2017 11:13 PM >>>>>> To: Ted Woodward <ted.woodw...@codeaurora.org> >>>>>> Cc: LLDB <lldb-dev@lists.llvm.org> >>>>>> Subject: Re: [lldb-dev] non-stop mode with lldb-mi? >>>>>> >>>>>> Please check `-gdb-set target.async` option. Probably that's what >>>>>> you >>>> need. >>>>>> >>>>>> On Thu, Feb 2, 2017 at 1:44 AM, Ted Woodward via lldb-dev <lldb- >>>> d...@lists.llvm.org> wrote: >>>>>>> Does lldb-mi support non-stop mode? >>>>>>> >>>>>>> If so, is there a way to set it besides “settings set >>>>>>> target.non-stop-mode >>>> true”? >>>>>>> >>>>>>> -- >>>>>>> Qualcomm Innovation Center, Inc. >>>>>>> The Qualcomm Innovation Center, Inc. is a member of Code Aurora >>>> Forum, a Linux Foundation Collaborative Project >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> lldb-dev mailing list >>>>>>> lldb-dev@lists.llvm.org >>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> - Ilia >>>>>> _______________________________________________ >>>>>> lldb-dev mailing list >>>>>> lldb-dev@lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>>> >>>>> _______________________________________________ >>>>> lldb-dev mailing list >>>>> lldb-dev@lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>> >>> > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
