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 state thread, and then that would wake up and
then it would be the one to call the OS Plugin to do it's job. That's how the
GDBRemote plugin works, for instance.
Jim
> On Feb 21, 2019, at 2:54 PM, Tatyana Krasnukha
> <tatyana.krasnu...@synopsys.com> wrote:
>
> That clarified things, thanks!
>
> I think, this is the reason:
>
> ProcessRunLock &Process::GetRunLock() {
> if (m_private_state_thread.EqualsThread(Host::GetCurrentThread()))
> return m_private_run_lock;
> else
> return m_public_run_lock;
> }
>
> In our case the current thread is not m_private_state_thread. I create a
> separate thread for waiting a processor to halt and then SetPrivateState. It
> seems, that was an inappropriate approach.
>
> -----Original Message-----
> From: jing...@apple.com <jing...@apple.com>
> Sent: Thursday, February 21, 2019 11:58 PM
> To: Tatyana Krasnukha <tatyana.krasnu...@synopsys.com>
> Cc: Alexander Polyakov <polyakov....@gmail.com>; LLDB
> <lldb-dev@lists.llvm.org>
> Subject: 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
>> <lldb-dev@lists.llvm.org> wrote:
>>
>>> lldb Process::SetPrivateState (stopped) stop_id = 2
>>> error: error: process must be stopped.
>>
>> These two lines are printed from different threads, you cannot be sure the
>> real order of execution is the same.
>>
>> The plugin should subscribe on public state change events and wait until one
>> comes (correct me if I’m wrong about that).
>
> That's not right. When the process stops, but before lldb broadcasts a
> public stop event, it will query the OS Plugin directly to build up the
> thread list. It needs to do that before it declares a public stop because it
> uses the thread list to reason about whether to declare a public stop or not.
> So the OS Plugin (and BTW the Thread Step Plan plugin is in the same boat)
> have to run after a private stop but before public one. There isn't a
> principled way to do that. The best we have at present is a hack that says
> "if you are running on the private state thread, then you get to do things
> between private & public stop as if there were a public stop". Cleaning that
> up is item 5 on the lldb Projects page if anyone is interested...
>
> Jim
>
>>
>> From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of
>> Alexander Polyakov via lldb-dev
>> Sent: Thursday, February 21, 2019 9:54 PM
>> To: Jim Ingham <jing...@apple.com>
>> Cc: LLDB <lldb-dev@lists.llvm.org>
>> Subject: Re: [lldb-dev] SB API is not working properly with OSPython
>> plugin
>>
>> 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 Process::PrivateResume() m_stop_id = 1, public state:
>> stopped private state: stopped
>> lldb Process::SetPrivateState (running)
>> intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state:
>> running, last broadcast state: running - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new
>> state running (old state stopped) to public
>> intern-state Process::PushProcessIOHandler pushing IO handler
>> intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1
>> lldb Process thinks the process has resumed.
>> intern-state timeout = <infinite>, event_sp)...
>> lldb waited from m_iohandler_sync to change from 0. New value is
>> 1.
>> dbg.evt-handler Process::SetPublicState (state = running, restarted =
>> 0) Process 1 resuming
>> lldb Process::SetPrivateState (stopped)
>> lldb Process::SetPrivateState (stopped) stop_id = 2
>> error: error: process must be stopped.
>> intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new
>> state: stopped, last broadcast state: stopped - YES
>> intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new
>> state stopped (old state running) to public
>> intern-state timeout = <infinite>, event_sp)...
>> dbg.evt-handler Process::SetPublicState (state = stopped, restarted =
>> 0) dbg.evt-handler Process::SetPublicState (stopped) -- unlocking run
>> lock
>>
>>
>> On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham <jing...@apple.com> wrote:
>> 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 <polyakov....@gmail.com>
>> wrote:
>>
>> 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 <jing...@apple.com> wrote:
>> 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, and
>> see why it isn’t allowing this call on private stop.
>>
>> Jim
>>
>>
>>
>> On Feb 14, 2019, at 11:50 AM, Alexander Polyakov <polyakov....@gmail.com>
>> wrote:
>>
>> Sure, could you describe in more detail which example may help you?
>>
>> чт, 14 февр. 2019 г. в 22:36, Jim Ingham <jing...@apple.com>:
>> 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 thread in lldb, and then if the
>> stop is judged interesting to the user, it gets rebroadcast as a public stop.
>>
>> For instance, when you issue a “step” command, lldb will stop and start the
>> process multiple times as it walks through the source line. But only the
>> last of those stops are relevant to the user of LLDB, so all the other ones
>> exist only as private stops.
>>
>> The SB API’s for the most part should only consider a “publicly stopped”
>> process accessible. After all, you wouldn’t want some API to succeed
>> sometimes if you happen to catch it in the middle of a private stop.
>>
>> But the OperatingSystem plugin needs to get called right after a private
>> stop, so it can provide threads for the ShouldStop mechanism. We should
>> really have some formal mechanism whereby things like the OS plugin can
>> request elevated rights in the SB API’s, so that they can run at private
>> stop time. IIRC, we instead have a hack where SB API calls that run on the
>> private state thread are blanket allowed to run at private stop. The xnu
>> Operating System plugin successfully gets global values to look up its
>> threads. So I’m not sure why that isn’t working for you.
>>
>> Can you cook up a simple example showing the failure and I’ll have a look?
>>
>> Jim
>>
>>
>>
>> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov <polyakov....@gmail.com>
>> wrote:
>>
>> 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 <jing...@apple.com> wrote:
>> 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
>> <lldb-dev@lists.llvm.org> wrote:
>>
>> 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’,
>> 1).GetValueAtIndex(0)
>>
>> When I do `print(ready_tasks)` I get:
>> No value
>>
>> At the same time, doing the same actions inside lldb embedded interpreter
>> follows to:
>> `
>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueA
>> tIndex(0))`
>>
>> (List_t [5]) pxReadyTasksLists = {
>> [0] = {
>> uxNumberOfItems = 0
>> pxIndex = 0x00000000
>> xListEnd = {
>> xItemValue = 0
>> pxNext = 0x00000000
>> pxPrevious = 0x00000000
>> }
>> }
>> …
>>
>> Does anybody know what may cause such a behavior?
>>
>> --
>> Alexander
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cg
>> i-2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&
>> r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=WSyRR4BN6X_gz6_8T2fa08
>> 4mE5gtQoySTdLAbss52z8&s=WwMtr2kl4vphhXJdM2gFv9aEZVPMgghJUnsTikIzfNE&e=
>>
>>
>>
>> --
>> Alexander
>>
>> --
>> Alexander
>>
>>
>>
>> --
>> Alexander
>>
>>
>>
>> --
>> Alexander
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cg
>> i-2Dbin_mailman_listinfo_lldb-2Ddev&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=WSyRR4BN6X_gz6_8T2fa084mE5gtQoySTdLAbss52z8&s=WwMtr2kl4vphhXJdM2gFv9aEZVPMgghJUnsTikIzfNE&e=
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
