It’s unclear to me why it would be a problem to listen to every thread object?
They aren’t terribly chatty or anything, and you can listen to all of them with
one listener.
Note, you don’t have to sign up individually for every thread object’s
broadcaster. That would be really annoying. In
I'm building an X11 UI on top of LLDB, and I'm stuck trying to listen for
thread events.
lldb_private::Thread is a Broadcaster, but lldb::SBThread doesn't expose a
GetBroadcaster() event the way SBProcess does.
I wouldn't really want to have to listen to every SBThread object, but when
the
Hi,
Normally if you want to attach to a process you only have the pid/name of
the process. How do you get SBTarget? Am I supposed to call
SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
we require a dummy SBTarget before attaching? This seems to be a wrong
design to
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