Hi Jeffrey,
I see a couple of problems with the way you are using the lldb's API.
The main problem is you are launching the target via the command-line
API, which does not allow you to specify the listener upon creation.
When you start it this way all events go to the default debugger
listener (de
Great, this is very helpful, will give a try.
Btw: is there any threading requirement of lldb API? For example, are all the
Apis must be called on the event thread or they are free to be called on any
thread? I know windows debug API has some limitation on this.
Sent from my iPad
> On Jan 29, 2
There is no requirement that the lldb API’s be called on a particular thread on
OS X. LLDB tries to be robust against being called from multiple threads
simultaneously for the same debugger, but you can still make it fall over if
you try hard, particularly if you allow multiple threads to resta
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.
Just curious, why does Xcode create multiple SBDebuggers assuming it is
debugging a single process? Are you talking about multiple-processes
scenario(One SBDebugger for
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, an
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 withou
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.
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
> on the way it is
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 progra
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 l
Hi Omair,
In a very real sense, no information is lost here. The addition of the ‘l’
only indicates that the system is little endian. When the triple is created,
the flag setting little endian is set (and defaults to little anyway). There
is no other valid ARM sub architecture with ARMv6 or
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 me.
12 matches
Mail list logo
