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.fun
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
> wrote:
>
> Does the following qualify as
On 15 September 2016 at 16:15, Zachary Turner wrote:
> lldb-commits to bcc, lldb-dev to cc.
>
>> The biggest feature I see missing here is the ability to run tests
>> remotely. Remote debugging is the most important use case for our team, and
>> now we have a number of (experimental) bots running
I found another issue, Daniel:
GDBRemoteCommunicationClient::GetWatchpointSupportInfo calls
SendPacketAndWaitForResponse, and assumes that a return of
PacketResult::Success means that qWatchpointSupportInfo is handled by the
remote server. That's not true; a null response also returns
PacketRe
lldb-commits to bcc, lldb-dev to cc.
> The biggest feature I see missing here is the ability to run tests
remotely. Remote debugging is the most important use case for our team, and
now we have a number of (experimental) bots running the remote test suite.
We want to make sure we can debug correct
