Ah, perfect. Works like a charm, thanks! -Greg
On Monday, April 23, 2012 at 3:32 PM, Jim Ingham wrote: > There's a more complicated SBTarget::Launch in SBTarget.h that takes a path > for the target's stdout/stdin/stderr. Should be able to get the tty path for > the current terminal and use that. > > Jim > > > On Apr 23, 2012, at 3:22 PM, Greg Hazel wrote: > > > 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 <[email protected] > > > (mailto:[email protected])> 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 > > > > > [email protected] (mailto:[email protected]) > > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > > > > > > > > > _______________________________________________ > > > > lldb-dev mailing list > > > > [email protected] (mailto:[email protected]) > > > > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > > > > > > > > > > > > > _______________________________________________ > > lldb-dev mailing list > > [email protected] (mailto:[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
