[lldb-dev] SB API is not working properly with OSPython plugin

[Alexander Polyakov via lldb-dev]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190215/d8422bc1/attachment.html>