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).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@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>
>> --
>> Alexander
>>
>>
>> --
> Alexander
>
>
>
--
Alexander
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
