Great, thanks for the confirmation.
Sent from my iPhone
> On Feb 1, 2016, at 1:32 AM, Pavel Labath wrote:
>
>> On 29 January 2016 at 18:43, Jeffrey Tan wrote:
>> Thanks Jim. Is this true for other platforms? Our IDE is going to support
>> Mac and
On 29 January 2016 at 18:43, Jeffrey Tan wrote:
> Thanks Jim. Is this true for other platforms? Our IDE is going to support
> Mac and Linux and may extend to Windows some time later.
AFAIK, windows spawns a separate thread to do the actual debugging,
but this is hidden
Thanks. That's fine, just want to confirm the behavior and my
understanding. I can definitely deal with the difference between
attach/launch myself.
On Fri, Jan 29, 2016 at 1:41 PM, Jim Ingham wrote:
> I don’t think we can change this behavior, since other clients are relying
I don’t think we can change this behavior, since other clients are relying on
the way it is now.
In any case, attach won't return till it is successful, and presumably you know
you are attaching, so I don’t think there’s any ambiguity about what is going
on, even if you don’t get a stop event.
I can’t comment on Windows, I don’t know what requirements the Windows API’s
place on the debugger.
Its been a while since I’ve worked on Linux, but I don’t remember anything that
would privilege one thread over another.
lldb supports running multiple targets and processes in one debugger,
Jim/Pavel, my toy code works reliably after using SBListener with
SBTarget.Launch/Attach.
One thing I noticed is:
If I set "stop_at_entry=True" for SBTarget.Launch(), I will get a stop
event of eStopReasonSignal at loader breakpoint. However
SBTarget.AttachXXX() will pause the target process
Hi,
On mac OS, I am having difficulty understanding the launch debugger events
sequence of lldb. I used the following code to play around LLDB. I found,
for some binaries, debugger will enter stopped/paused mode, waiting for my
further input, print stack shows:
dbg> bt
* thread #1: tid =