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
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
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.
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
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
Ah, perfect. Works like a charm, thanks!
-Greg
That worked at the time, but something seems to have broken the python wrapper for the long version of SBTarget::Launch. Probably in 10.8.something
This works:
target.LaunchSimple([‘X’, ‘Y’, ‘Z’], None, os.getcwd())
This does not:
target.Launch(debugger.GetListener(), [‘X’, ‘Y’, ‘Z’], None,
None, ‘/tmp/stdout.txt’, None,
None, 0, False, error)
The error is:
File “/System/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/Python/lldb/init.py”, line 6351, in Launch
return _lldb.SBTarget_Launch(self, *args)
NotImplementedError: Wrong number of arguments for overloaded function ‘SBTarget_Launch’.
Possible C/C++ prototypes are:
Launch(lldb::SBTarget *,lldb::SBListener &,char const **,char const **,char const *,char const *,char const *,char const *,uint32_t,bool,lldb::SBError &)
Launch(lldb::SBTarget *,lldb::SBLaunchInfo &,lldb::SBError &)
Passing None for the argv parameter works fine, but a list or a tuple (even empty) gives that error.
-Greg
How are you creating the error you are passing in the last argument? It should be:
error = lldb.SBError()
target.Launch(debugger.GetListener(),
['X', 'Y', 'Z'],
None,
None,
'/tmp/stdout.txt',
None,
None,
0,
False,
error);
I would suggest using:
SBProcess
SBTarget::Launch (SBLaunchInfo &launch_info, SBError& error);
If possible as this is the future of our API. Other will eventually be removed.
launch_info = lldb.SBLaunchInfo (['X', 'Y', 'Z'])
# The '1' below is for STDOUT_FILENO
launch_info.AddOpenFileAction (1, '/tmp/stdout.txt')
error = lldb.SBError()
process = target.Launch (launch_info, error)
When you don't care about the error, you can pass a temporary:
process = target.Launch (launch_info, lldb.SBError())
error = lldb.SBError()
as in the example.
I tried your LaunchInfo method, which sounds promising, but I got:
Traceback (most recent call last):
File "crundebug", line 20, in <module>
launch_info.AddOpenFileAction(1, '/tmp/stdout.txt')
File "/System/Library/PrivateFrameworks/LLDB.framework/Versions/A/Resources/Python/lldb/__init__.py", line 6029, in AddOpenFileAction
return _lldb.SBLaunchInfo_AddOpenFileAction(self, *args)
TypeError: SBLaunchInfo_AddOpenFileAction() takes exactly 5 arguments (3 given)
-Greg
Woops, I forgot the two read and write args. Try this:
launch_info.AddOpenFileAction (1, '/tmp/stdout.txt', False, True)
Ah, got it. That works. Thanks again!
-Greg