Re: [lldb-dev] non-stop mode with lldb-mi?
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 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 >> Cc: Greg Clayton ; LLDB >> Subject: Re: [lldb-dev] non-stop mode with lldb-mi? >> >> >>> 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 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 >>>> Cc: Ted Woodw
Re: [lldb-dev] non-stop mode with lldb-mi?
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 > Cc: Greg Clayton ; LLDB > Subject: Re: [lldb-dev] non-stop mode with lldb-mi? > > > > 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 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 > >> Cc: Ted Woodward ; 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 >> 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... B
Re: [lldb-dev] non-stop mode with lldb-mi?
> 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 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 >> Cc: Ted Woodward ; 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 > 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 > 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 >>>> Cc: LLDB >>>> 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 > 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. &
Re: [lldb-dev] non-stop mode with lldb-mi?
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. -- 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 > Cc: Ted Woodward ; 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 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 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 > >> Cc: LLDB > >> 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 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
Re: [lldb-dev] non-stop mode with lldb-mi?
> 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 > 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 >> 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 >> Cc: LLDB >> 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 >> 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
Re: [lldb-dev] non-stop mode with lldb-mi?
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 > On Feb 3, 2017, at 7:54 AM, Ted Woodward via lldb-dev > 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 > Cc: LLDB > 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 > mailto:lldb-dev@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 <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> <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
Re: [lldb-dev] non-stop mode with lldb-mi?
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 Cc: LLDB 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 mailto:lldb-dev@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 <mailto: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
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@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] 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"? -- 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
