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