[lldb-dev] lldb batch mode

Greg Clayton gclayton at apple.com
Mon Oct 15 18:10:23 PDT 2012


Woops, I forgot the two read and write args. Try this:

	launch_info.AddOpenFileAction (1, '/tmp/stdout.txt', False, True)

On Oct 15, 2012, at 6:05 PM, Greg Hazel <ghazel at gmail.com> wrote:

> 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
> 
> On Oct 15, 2012, at 5:57 PM, Greg Clayton <gclayton at apple.com> wrote:
> 
>> 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())
>> 
>> 
>> 
>> On Oct 15, 2012, at 12:47 PM, ghazel at gmail.com wrote:
>> 
>>> 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
>>> 
>>> 
>>> On Mon, Apr 23, 2012 at 4:09 PM, Greg Hazel <ghazel at gmail.com> wrote:
>>> 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 <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
>>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> lldb-dev mailing list
>>>>>>> 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
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>> 
>>> 
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
> 




More information about the lldb-dev mailing list