[lldb-dev] SB API is not working properly with OSPython plugin
Alexander Polyakov via lldb-dev
lldb-dev at lists.llvm.org
Thu Feb 21 10:53:49 PST 2019
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 <jingham at 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.alx at 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 <jingham at 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.alx at gmail.com>
>> wrote:
>>
>> Sure, could you describe in more detail which example may help you?
>>
>> чт, 14 февр. 2019 г. в 22:36, Jim Ingham <jingham at 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.alx at 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 <jingham at 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 at 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).GetValueAtIndex(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 at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>>
>>>>
>>>>
>>>
>>> --
>>> Alexander
>>>
>>>
>>> --
>> Alexander
>>
>>
>>
>
> --
> Alexander
>
>
>
--
Alexander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190221/b3c1444e/attachment-0001.html>
More information about the lldb-dev
mailing list