> lldb Process::SetPrivateState (stopped) stop_id = 2 > error: error: process must be stopped.
These two lines are printed from different threads, you cannot be sure the real order of execution is the same. The plugin should subscribe on public state change events and wait until one comes (correct me if I’m wrong about that). From: lldb-dev <lldb-dev-boun...@lists.llvm.org> On Behalf Of Alexander Polyakov via lldb-dev Sent: Thursday, February 21, 2019 9:54 PM To: Jim Ingham <jing...@apple.com> Cc: LLDB <lldb-dev@lists.llvm.org> Subject: Re: [lldb-dev] SB API is not working properly with OSPython plugin It seems that the process plugin uses the Process::SetPrivateState at the right time. If you look at the log, you will see that the process is already in the 'private stopped' state when the OS plugin is invoked. (lldb) c lldb Process::Resume -- locking run lock lldb Process::PrivateResume() m_stop_id = 1, public state: stopped private state: stopped lldb Process::SetPrivateState (running) intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: running, last broadcast state: running - YES intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state running (old state stopped) to public intern-state Process::PushProcessIOHandler pushing IO handler intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1 lldb Process thinks the process has resumed. intern-state timeout = <infinite>, event_sp)... lldb waited from m_iohandler_sync to change from 0. New value is 1. dbg.evt-handler Process::SetPublicState (state = running, restarted = 0) Process 1 resuming lldb Process::SetPrivateState (stopped) lldb Process::SetPrivateState (stopped) stop_id = 2 error: error: process must be stopped. intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new state: stopped, last broadcast state: stopped - YES intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state stopped (old state running) to public intern-state timeout = <infinite>, event_sp)... dbg.evt-handler Process::SetPublicState (state = stopped, restarted = 0) dbg.evt-handler Process::SetPublicState (stopped) -- unlocking run lock On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham <jing...@apple.com<mailto:jing...@apple.com>> wrote: 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<mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_lldb-2Ddev&d=DwMFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=yfnu24japkhNGh-WqJObHXmH3mINtC_2FO828lrNpM0&m=KP5ET5dWEqC5tPKmPwJuRQhPRke995h7KcoxdU2oPt8&s=EfL7fZPd3cUxemafYKOKALqtQW_6ujxeTw0ZaxKKqR8&e=> -- Alexander -- Alexander -- Alexander -- Alexander
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
