On Mar 18, 2014, at 3:25 AM, Hikaru Gosun <[email protected]> wrote:
> Oops, thanks Greg!
>
> Also it seems that I was not setting up the listener in a proper way, I
> needed to do debugger.GetListener() instead of my
> lldb.SBListener("event_listener") which I copy&pasted from somewhere else :(
Yes, when you currently launch with SBLaunchInfo, you don't get to specify your
own listener. We should fix this so that you can supply your own listener to
the SBLaunchInfo, and if you don't specify a valid listener, then the debugger
will be used. The debugger is currently always used as the listener when using
the SBLaunchInfo based SBTarget::Launch() function. If you ever do want to use
your own listener you can use the following SBTarget launch:
lldb::SBProcess
Launch (SBListener &listener,
char const **argv,
char const **envp,
const char *stdin_path,
const char *stdout_path,
const char *stderr_path,
const char *working_directory,
uint32_t launch_flags, // See LaunchFlags
bool stop_at_entry,
lldb::SBError& error);
Then you could have specified your "listener" as the first parameter. You also
would have needed to do the following line:
process.GetBroadcaster().AddListener(listener,
lldb.SBProcess.eBroadcastBitStateChanged)
A process requires a listener up front when launching or attaching, so it
always already has one when you get a valid SBProcess instance back. We also
currently don't support more than one listener for a process' stop events. We
need to have any additional listeners fail to be added, but we currently don't
enforce that and that is a bug. Why you might ask? Because what does it mean to
get a "I am a process and I have stopped" if someone else on another thread
already received that event and sent a process.Continue()? Two clients
currently can't react effectively to stop and run events as they would be
stomping on each other. If you get a stop event and start asking the process
for its thread list and the other thread that got the stop event had continued
your process, you would have real trouble getting valid results.
So for now it is definitely best to only have 1 thing listening and reacting to
process state change events.
Greg
> Working smoothly now. Thanks a lot,
> HG
>
>
> On Mon, Mar 17, 2014 at 6:14 PM, Greg Clayton <[email protected]> wrote:
> Yes, you aren't checking if the process state. See the python example in the
> SVN repository:
>
> svn cat
> http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/process_events.py
>
> It does the process events correctly and should serve as a great starting
> point for you.
>
>
> On Mar 17, 2014, at 9:29 AM, Hikaru Gosun <[email protected]> wrote:
>
> > Hi,
> >
> > I have a small script to debug a program in OSX that looks more or less
> > like this:
> >
> > debugger = lldb.SBDebugger.Create()
> > target = debugger.CreateTargetWithFileAndArch(exe,
> > lldb.LLDB_ARCH_DEFAULT_64BIT)
> > launch_info = lldb.SBLaunchInfo(args)
> > launch_info.SetLaunchFlags(lldb.eLaunchFlagNone)
> > error = lldb.SBError()
> > process = target.Launch(launch_info, error)
> > if not error.Success():
> > print args, str(error)
> > return
> >
> > listener = lldb.SBListener("event_listener")
> > process.GetBroadcaster().AddListener(listener,
> > lldb.SBProcess.eBroadcastBitStateChanged)
> > done = 0
> > while not done:
> > event = lldb.SBEvent()
> > if listener.WaitForEvent(10, event):
> > state = lldb.SBProcess.GetStateFromEvent(event)
> > print state
> > for thread in process:
> > print thread, thread.GetFrameAtIndex(0)
> > process.Continue()
> > else:
> > done = 1
> >
> > My intention is to debug the target with some kind of timeout, that's why
> > I'm trying to use the async mode and use the timeout in WaitForEvent(). The
> > problem that I'm facing is that once WaitForEvent() succeeds, there's no
> > way I can get access to the thread information (for example to get frame
> > info for each thread). This is the output from the script:
> >
> > 5
> > SBThread: tid = 0x2b9672 No value
> > SBThread: tid = 0x2b9686 No value
> > SBThread: tid = 0x2b9687 No value
> > SBThread: tid = 0x2b9689 No value
> > SBThread: tid = 0x2b968a No value
> > SBThread: tid = 0x2b96be No value
> > SBThread: tid = 0x2b96bf No value
> > SBThread: tid = 0x2b96c0 No value
> >
> > This is for the lldb version that comes with XCode (lldb-300.2.53)
> >
> > Any ideas? Is there anything wrong with my approach?
> >
> > Thanks,
> > HG
> > _______________________________________________
> > lldb-dev mailing list
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
