This is an archive of the discontinued LLVM Phabricator instance.

Allow private-state-thread to call SB API's that take the TargetAPI mutex
ClosedPublic

Authored by jingham on Sep 27 2019, 6:27 PM.

Details

Summary

When we do synchronous process execution in lldb, the call that restarted the target will generally have acquired first the TargetAPI lock, and then the Process RunLock. If in the process of handling that continue we need to run Python code in the private-state-thread (e.g. for an OS plugin or scripted ThreadPlan) if that Python code calls another API that takes the Target API mutex, we will deadlock. However, the private state thread is always doing work on behalf of whatever thread initiated the continue. So the private state thread should always formally be allowed to pass the lock check.

We already handled this in the case of the Process RunLock by passing out separate locks depending on whether you were running code in the private state thread or anywhere else. This patch just does the same thing for the Target API mutex.

I also added a test using a scripted ThreadPlan that calls various SBFrame and SBValue API's which take the API lock in the should_stop method of the plan (which is always run on the private state thread).

Diff Detail

Repository
rL LLVM

Event Timeline

jingham created this revision.Sep 27 2019, 6:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 27 2019, 6:27 PM

Note, a better way to do this would be to have some kind of "API/Runlock baton" that could get handed off from the thread that initiated the continue to the private state thread, then handed back when the process stops and returns control to the SB API that initiated the run. But I don't have time to design such a thing right now, and this was blocking writing tests for some work I am doing to handle the case where OS Plugins don't report all threads at each stop. So I'd prefer this more straightforward solution for now - especially since it's just a copy of the way we handled the same problem for the runlock.

This revision was not accepted when it landed; it landed in state Needs Review.Sep 30 2019, 5:45 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2019, 5:45 PM