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

[Jim Ingham via lldb-dev]

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:lldb-dev at lists.llvm.org>
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev>
>> 
>> 
>> 
>> -- 
>> Alexander
> 
> -- 
> Alexander

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190214/f0b9dfe8/attachment.html>