: Alexander Polyakov ; LLDB
Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin
What's triggering one of the OS Plugin methods to get run on this separate
thread? I would expect SetPrivateState would just cause the private stop event
to get broadcast to the private
en SetPrivateState. It
> seems, that was an inappropriate approach.
>
> -Original Message-
> From: jing...@apple.com
> Sent: Thursday, February 21, 2019 11:58 PM
> To: Tatyana Krasnukha
> Cc: Alexander Polyakov ; LLDB
>
> Subject: Re: [lldb-dev] SB API is not working prop
ject: Re: [lldb-dev] SB API is not working properly with OSPython plugin
> On Feb 21, 2019, at 11:22 AM, Tatyana Krasnukha via lldb-dev
> wrote:
>
> > lldb Process::SetPrivateState (stopped) stop_id = 2
> > error: error: process must be stopped.
>
> T
em 5 on the lldb
Projects page if anyone is interested...
Jim
>
> From: lldb-dev On Behalf Of Alexander
> Polyakov via lldb-dev
> Sent: Thursday, February 21, 2019 9:54 PM
> To: Jim Ingham
> Cc: LLDB
> Subject: Re: [lldb-dev] SB API is not working properly with OSPytho
il one
comes (correct me if I’m wrong about that).
From: lldb-dev On Behalf Of Alexander
Polyakov via lldb-dev
Sent: Thursday, February 21, 2019 9:54 PM
To: Jim Ingham
Cc: LLDB
Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin
It seems that the process plugin us
It seems that the process plugin uses the Process::SetPrivateState at the
right time. If you look at the log, you will see that the process is
already in the '*private* *stopped'* state when the OS plugin is invoked.
(lldb) c
lldb Process::Resume -- locking run lock
lldb Pr
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
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_
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,
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
>
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
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).
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
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
14 matches
Mail list logo
