[lldb-dev] non-stop mode with lldb-mi?

Fri Feb 3 12:35:30 PST 2017

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.woodward at 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: jingham at apple.com [mailto:jingham at apple.com]
>> Sent: Friday, February 03, 2017 1:22 PM
>> To: Ted Woodward <ted.woodward at codeaurora.org>
>> Cc: Greg Clayton <gclayton at apple.com>; LLDB <lldb-dev at lists.llvm.org>
>> Subject: Re: [lldb-dev] non-stop mode with lldb-mi?
>> 
>> 
>>> On Feb 3, 2017, at 10:51 AM, Ted Woodward
>> <ted.woodward at 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: jingham at apple.com [mailto:jingham at apple.com]
>>>> Sent: Friday, February 03, 2017 10:58 AM
>>>> To: Greg Clayton <gclayton at apple.com>
>>>> Cc: Ted Woodward <ted.woodward at codeaurora.org>; LLDB <lldb-
>>>> dev at 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-
>>>> dev at 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-
>>>> dev at 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.stfu at gmail.com]
>>>>>> Sent: Wednesday, February 01, 2017 11:13 PM
>>>>>> To: Ted Woodward <ted.woodward at codeaurora.org>
>>>>>> Cc: LLDB <lldb-dev at 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-
>>>> dev at 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 at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> - Ilia
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing list
>>>>>> lldb-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>> 
>>>>> _______________________________________________
>>>>> lldb-dev mailing list
>>>>> lldb-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>> 
>>> 
> 
> 