When using the "script" command, lldb.process/thread/frame are always setup so you can use them _in_your_text_, but you probably shouldn't rely on them being setup inside your function. You should pass the process to it:
(lldb) script myfile.func(lldb.process, args) Then you can use "myfile.func" from any other function, including one that comes from a command, breakpoint python function, etc and the process will always be specified. If you wan't to run a python function as a new LLDB command, install a new command line command: http://lldb.llvm.org/python-reference.html See the section named: CREATE A NEW LLDB COMMAND USING A PYTHON FUNCTION Greg > On Sep 14, 2016, at 10:24 PM, Lei Kong <leik...@msn.com> wrote: > > Does the following qualify as "interactive usage"? It seems using "process" > works in myfile.func(), or I was just lucky? Thanks. > > (lldb) script myfile.func(args) > > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid > > From: gclay...@apple.com > > Date: Wed, 14 Sep 2016 09:33:20 -0700 > > CC: egran...@apple.com; lldb-dev@lists.llvm.org > > To: leik...@msn.com > > > > > > > On Sep 13, 2016, at 9:50 PM, Lei Kong via lldb-dev > > > <lldb-dev@lists.llvm.org> wrote: > > > > > > Thanks! > > > SBValue.process works! > > > > > > I have another script that I run manually to search process memory for > > > certain patterns, not a type summary provider, there is no SBValue passed > > > to my script, in such a case, how do I get current process? > > > > > If this is python a command line command you are making, use the variant > > that takes an execution context: > > > > def my_command(debugger, command, exe_ctx, result, dict): > > # Always use the specified execution context to get the target, process > > # thread and frame. If this command gets run from a breakpoint callback > > # these will not match the debugger's selected target, the selected > > # process in the target, the selected thread in the process and the > > # selected frame in the thread. > > target = exe_ctx.GetTarget() > > process = exe_ctx.GetProcess() > > thread = exe_ctx.GetThread() > > frame = exe_ctx.GetFrame() > > > > > > The execution context is explicitly specified for you. > > > > > From: Enrico Granata > > > Sent: Tuesday, September 13, 2016 10:31 AM > > > To: Lei Kong > > > Cc: lldb-dev@lists.llvm.org > > > Subject: Re: [lldb-dev] lldb type summary provider - SBProcess is invalid > > > > > > > > >> On Sep 13, 2016, at 10:02 AM, Lei Kong via lldb-dev > > >> <lldb-dev@lists.llvm.org> wrote: > > >> > > >> I wrote a lldb type summary provider for wstring with 16bit wchar on > > >> Ubuntu 16.04. > > >> > > >> Things work fine if I manually do the following in lldb: > > >> > > >> (lldb) script import mytypes > > >> (lldb) type summary add -F mytypes.wstring_SummaryProvider > > >> "std::__1::wstring" > > >> > > >> I tried to make things easier with auto-loading by adding the following > > >> to .lldbinit: > > >> > > >> script import mytypes > > >> type summary add -F mytypes.wstring_SummaryProvider "std::__1::wstring" > > >> > > >> Then I got a failure of "SBProcess is invalid" when printing a wstring > > >> variable. > > >> > > >> My type summary function has the following, which I believe is where the > > >> error is encountered: > > >> > > >> content = lldb.process.ReadMemory(bufferAddr, byteCount, error) > > >> > > >> Maybe this is because "process" is not assigned yet when the type > > >> summary is added during auto-loading? Or this is a bug in lldb? Does > > >> anyone know how to work around this issue? > > >> > > >> > > > > > > Good hunch :-) > > > Maybe we should do a better job at documenting this, but > > > http://lldb.llvm.org/python-reference.html reads > > > > > > "While extremely convenient, these variables (lldb.process et alia) have > > > a couple caveats that you should be aware of. First of all, they hold the > > > values of the selected objects on entry to the embedded interpreter. They > > > do not update as you use the LLDB API's to change, for example, the > > > currently selected stack frame or thread. > > > Moreover, they are only defined and meaningful while in the interactive > > > Python interpreter. There is no guarantee on their value in any other > > > situation, hence you should not use them when defining Python formatters, > > > breakpoint scripts and commands (or any other Python extension point that > > > LLDB provides). As a rationale for such behavior, consider that lldb can > > > run in a multithreaded environment, and another thread might call the > > > "script" command, changing the value out from under you." > > > > > > As part of a formatter, you get passed an SBValue. One of the things you > > > can ask of an SBValue is the process it came from, thusly: > > > > > > value.GetProcess() > > > > > > That's the SBProcess object you want to use > > > > > >> > > >> Thanks much > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> lldb-dev mailing list > > >> lldb-dev@lists.llvm.org > > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > > > > > > > Thanks, > > > - Enrico > > > egranata@.com ️ 27683 > > > > > > _______________________________________________ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
