non-stop mode with lldb-mi?

Does lldb-mi support non-stop mode?

If so, is there a way to set it besides “settings set target.non-stop-mode true”?

Please check -gdb-set target.async option. Probably that’s what you need.

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.

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.

Greg

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

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.

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

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.

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