Hi Greg, Thanks for your feedback.
> So I would suggest not using "ci.HandleCommand()" if you can. There are > better API calls for this that will return your the objects that you need. I realise this, but the only reason I’m writing code that instantiates the debugger and controls this itself is because I cannot get the callbacks I need from the regular LLDB CLI driver (previous discussion here: http://lists.cs.uiuc.edu/pipermail/lldb-dev/2013-October/002554.html) I would *really* rather not have to reimplement the entire CLI myself, I just want some additional callbacks on top of LLDB’s CLI - which is why I’m using SBCommandInterpreter in the contrived example. > Why is it blocking? You should look at a sample or interrupt with a debugger > and see why. OK I will look. > You should probably let the debugger handle everything including the command > interpreter. Just call: > > auto_handle_events = True > spawn_thread = False > > debugger.RunCommandInterpreter (auto_handle_events, spawn_thread) > > This will run everything for you just like the command line LLDB. If > spawn_thread is false, then it will block until the command interpreter is > exited, else if spawn_thread is true, the command interpreter will be run on > another thread and it will return allowing you to do other things. > > There currently isn't an option to just say "handle the events for me". The > built in one exposed in SBDebugger::RunCommandInterpreter(...) will always > print messages out to the stdout/stderr that you gave to the debugger: > > void > SBDebugger::SetInputFileHandle (FILE *f, bool transfer_ownership); > > void > SBDebugger::SetOutputFileHandle (FILE *f, bool transfer_ownership); > > void > SBDebugger::SetErrorFileHandle (FILE *f, bool transfer_ownership); RunCommandInterpreter() sounds like it may do what I want it to do, I will give it a try. > So if you don't want it to do that and provide the feedback just like the > command line tool, then you should be running your own event loop. Yeah this is what I’m trying to avoid, as above. Thanks, Loukas
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
