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 <[email protected]> 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, [email protected] 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 <[email protected]> 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 <[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]
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> lldb-dev mailing list
>>>>>> [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
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> [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
