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
