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.
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> r
> On Feb 3, 2017, at 10:51 AM, Ted Woodward 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 curren
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 vie
> On Feb 3, 2017, at 8:45 AM, Greg Clayton via lldb-dev
> 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
>
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
emu
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
Fou
