[lldb-dev] lldb batch mode

[Greg Hazel]

First off, thanks for your help!

I got both of those methods working to some extent, but both have little issues.

The pexpect approach outputs the lldb prompts and other output in addition to the backtrace, which is not ideal. (Also I can't seem to get it to terminate properly in the "Process .* exited with status" case..)

The Python HandleCommand approach lets me control lldb properly, but the stdout/stderr of the inferior is being swallowed. I found the parameters to redirect output to a file and the GetSTDOUT function, but not a way to just output stdout/err to the current terminal directly, as lldb itself seems to. It's pretty easy to build a thread that dumps GetSTDOUT/ERR, but the stdout/stderr wouldn't interleave quite the same way as they would without the buffering. Is there a way to get the same behavior as lldb?

-Greg 


On Monday, April 23, 2012 at 11:21 AM, Johnny Chen wrote:

> Hi Greg,
> 
> ToT/utils/test/run-until-faulted provides a similar scenario. Basically, it uses pexpect to spawn an lldb command line program,
> and to run the inferior until it faults and give the control back to the user to interact with lldb. You could easily modify it to
> just print out a backtrace and to give back the control or just exit the lldb program.
> 
> You're welcome to modify the thing or to add your handy utility.
> 
> Thanks.
> 
> On Apr 23, 2012, at 11:14 AM, Jim Ingham <jingham at apple.com (mailto:jingham at apple.com)> wrote:
> 
> > The lldb command line tool doesn't have a batch mode. Feel free to file a bug on this (or just add it yourself...) We haven't gotten around to this yet because most of the sort of thing you would do with more complex gdb scripts, we envisioned doing in Python instead.
> > 
> > What you want to do would be quite easy in Python. For instance, examples/python/disass.py has a quick example of launching a process & stopping at a breakpoint. That does pretty much what you want, you just want to catch any stop state bug eStateExited, enumerate the threads - there's an iterator for that in the process, so you can just do:
> > 
> > for t in process:
> > 
> > and then get the backtrace for the thread. There's a routine in test/lldbutils.py (print_stacktrace) that does a fairly fancy job of this, and of course you can always get the command interpreter from the debugger object and call HandleCommand to run an lldb command-line command... The data for the command comes back in the result object so you can print it to stdout, or some log file or whatever you want to do with it.
> > 
> > lldb's Python API's do have documentation that you can access in Python, or just look at the files in include/lldb/API, the C++ -> Python translation is pretty straight-forward.
> > 
> > The page:
> > 
> > http://lldb.llvm.org/python-reference.html
> > 
> > has some info on how to load the lldb module into stand-alone Python, which is probably what you want to do.
> > 
> > Hope this helps.
> > 
> > Jim
> > 
> > 
> > 
> > On Apr 20, 2012, at 10:55 PM, Greg Hazel wrote:
> > 
> > > Hi,
> > > 
> > > I'd like to run my process in lldb automatically, and print a backtrace if an error occurs but exit normally otherwise. This sort of thing can be achieved (sloppily) with gdb using something like this:
> > > 
> > > echo -e "run\nthread apply all bt" > foo.gdb
> > > gdb -batch -x foo.gdb my_process
> > > 
> > > Is something like this possible? I'd be willing to write some Python if needed.
> > > 
> > > -Greg
> > > 
> > > _______________________________________________
> > > lldb-dev mailing list
> > > lldb-dev at cs.uiuc.edu (mailto:lldb-dev at cs.uiuc.edu)
> > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > > 
> > 
> > 
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at cs.uiuc.edu (mailto:lldb-dev at cs.uiuc.edu)
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> > 
> 
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20120423/d95cda13/attachment.html>