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