Yes, the "script" command always sets up the lldb.{process/thread/frame}
regardless of whether its input is one-line or from the Script Input reader.
The help for script should specify that.
Jim
> On Sep 14, 2016, at 10:24 PM, Lei Kong via lldb-dev <lldb-dev@lists.llvm.org>
> 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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
