This is an archive of the discontinued LLVM Phabricator instance.

[lldb] [llgs] Fix disabling non-stop mode
ClosedPublic

Authored by mgorny on Jun 30 2022, 1:50 AM.

Details

Summary

Stop all processes and clear notification queues when disabling non-stop
mode. Ensure that no stop notifications are sent for processes stopped
due to the mode switch.

Sponsored by: The FreeBSD Foundation

Diff Detail

Event Timeline

mgorny created this revision.Jun 30 2022, 1:50 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 30 2022, 1:50 AM
Herald added a subscriber: arichardson. · View Herald Transcript

FYI, I don't feel very strongly about this. If you really dislike adding m_inhibit_stop_reason_processes, I suppose we could alternatively just declare disabling non-stop as unsupported and error out.

FYI, I don't feel very strongly about this. If you really dislike adding m_inhibit_stop_reason_processes, I suppose we could alternatively just declare disabling non-stop as unsupported and error out.

The problem is I "really disliked" the vKill part as well. I didn't want to make a big deal out of it, as I though it was an isolated use case, but now it seems like this may be a regular occurrence.

I think things would look better if we at least grouped all of the various bits of information about a single process. So, instead of three maps, we would have a single map, whose values would contain the process pointer, and any other state data we need. That could be a flag (whether the process is being killed), or maybe a callback (specifying the action to perform when the process stops). WDYT?

lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
1922–1924

if (m_inhibit_stop_reason_processes.erase(process.GetID()) != 0)

3951

Should we maybe send this *after* the stop dance is completed?

FYI, I don't feel very strongly about this. If you really dislike adding m_inhibit_stop_reason_processes, I suppose we could alternatively just declare disabling non-stop as unsupported and error out.

The problem is I "really disliked" the vKill part as well. I didn't want to make a big deal out of it, as I though it was an isolated use case, but now it seems like this may be a regular occurrence.

I think things would look better if we at least grouped all of the various bits of information about a single process. So, instead of three maps, we would have a single map, whose values would contain the process pointer, and any other state data we need. That could be a flag (whether the process is being killed), or maybe a callback (specifying the action to perform when the process stops). WDYT?

I suppose that makes sense.

mgorny marked an inline comment as done.Jul 13 2022, 9:05 AM
mgorny added inline comments.
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
1922–1924

This is now irrelevant with the flag field ;-).

mgorny updated this revision to Diff 444295.Jul 13 2022, 9:06 AM
mgorny marked 2 inline comments as done.

Implemented the requested changes.

Actually, on second thought (:D) do we even need a per-process flag for this?

Turning off non-stop should stop _all_ processes, so instead of checking whether there are any processes with the 'stopping-due-to-qnonstop` flag around, couldn't we just check if we have any unstopped processes altogether?

(This will require a global qnonstop-in-progress flag, but that's still better than a per-process flag.)

Hmm, I suppose that makes sense.

mgorny updated this revision to Diff 444727.Jul 14 2022, 10:49 AM

Use a single bool member to indicate whether we're still waiting for any process to stop. Turned out pretty easy.

labath accepted this revision.Jul 15 2022, 1:35 AM

Looks much better. Thanks.

This revision is now accepted and ready to land.Jul 15 2022, 1:35 AM
This revision was landed with ongoing or failed builds.Jul 15 2022, 11:17 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2022, 11:17 AM