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 <[email protected]> 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 <[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
