On Wed, Feb 13, 2019 at 9:39 PM Dimitry Andric
wrote:>> On 7 Feb 2019, at 16:41, Hans Wennborg via Release-testers
wrote:> > 8.0.0-rc2 has been tagged
from the release_80 branch at r353413.> >> > Please run the test
script, share your results, and upload binaries.>> Unfortunately I had
to disable
Hi lldb-dev,
I work on a custom implementation of OperatingSystem plugin using Python
and SB API. I’m trying to fetch information about some variables from the
target into the plugin, to do that I’m using the following Python code:
ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists
All SBValues have an error in them (SBValue.GetError). Does that say anything
interesting?
Jim
> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev
> wrote:
>
> Hi lldb-dev,
>
> I work on a custom implementation of OperatingSystem plugin using Python and
> SB API. I’m tryin
It is, the error is: *error: error: process must be stopped.*
I thought that the plugin (get_thread_info in my case) is invoked when the
process is already stopped, but it's not. Is it ok?
On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham wrote:
> All SBValues have an error in them (SBValue.GetError).
Good day -
I'd be most grateful if anyone could enlighten me as to how
to set a watchpoint on an unsigned short parameter variable
in lldb .
I am trying to follow the instructions at :
https://lldb.llvm.org/lldb-gdb.html
but they do not work to set watchpoints.
There seems to be
That’s a little complicated…
lldb has two levels of stop state - private stops and public stops. When the
process gets notification from the underlying process plugin that the process
stopped, it raises a private stop event. That gets handled by the ShouldStop
mechanism on the private state
Sure, could you describe in more detail which example may help you?
чт, 14 февр. 2019 г. в 22:36, Jim Ingham :
> That’s a little complicated…
>
> lldb has two levels of stop state - private stops and public stops. When
> the process gets notification from the underlying process plugin that the
>
The simplest thing possible to reproduce the failure. So some OS_Plugin
implementation which tries to look up a global like this and fails, and some
program source I can run it under that provides said global. That way I can
easily watch it fails as you describe when the plugin gets activated,
I found out that the plugin works well with an x86 application, so I think
that the problem is in my process plugin. Maybe you know a place where to
start looking for an issue?
On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham wrote:
> The simplest thing possible to reproduce the failure. So some OS_
Your plugin should have set the private state to stopped when it figures out
however it does that the process has stopped. The API is
Process::SetPrivateState. Is that happening at the right time?
Jim
> On Feb 14, 2019, at 1:50 PM, Alexander Polyakov
> wrote:
>
> I found out that the plug
10 matches
Mail list logo
