This is an archive of the discontinued LLVM Phabricator instance.

[lldb] [llgs] Support multiprocess in qfThreadInfo
ClosedPublic

Authored by mgorny on Jun 19 2022, 10:20 PM.

Details

Summary

Update the qfThreadInfo handler to report threads of all debugged
processes and include PIDs when in multiprocess mode.

Sponsored by: The FreeBSD Foundation

Diff Detail

Event Timeline

mgorny created this revision.Jun 19 2022, 10:20 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 19 2022, 10:20 PM
Herald added a subscriber: arichardson. · View Herald Transcript
mgorny requested review of this revision.Jun 19 2022, 10:20 PM
labath accepted this revision.Jun 21 2022, 8:05 AM
labath added inline comments.
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
2011

without multiprocess extensions, we should never have more than one process, right? Could we just unconditionally use the multiprocess loop here (perhaps with an assert(m_debugged_processes.size() == 1 || multiprocess)) ?

This revision is now accepted and ready to land.Jun 21 2022, 8:05 AM
mgorny marked an inline comment as done.Jun 21 2022, 8:42 PM
mgorny added inline comments.
lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
2011

Yes, that makes sense. We enable fork & vfork only if multiprocess is supported, so that shouldn't happen unless we deal with broken Process plugin.

mgorny updated this revision to Diff 438914.Jun 21 2022, 10:44 PM
mgorny marked an inline comment as done.

Simplify to use a single loop for both multiprocess and non-multiprocess modes. Replace the static function with include_pid with a class method, to prepare for adding a new helper to print PID+TID.

labath accepted this revision.Jun 22 2022, 11:51 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 24 2022, 8:20 AM
cmtice added a subscriber: cmtice.Jun 24 2022, 12:48 PM

Just FYI, this commit appears to cause lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py to fail. The error I'm seeing is:

Traceback (most recent call last):

File "../lldb/test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py", line 72, in test_target_auto_install_main_executable

self.expect("process launch", substrs=["exited with status = 74"])

File ".../lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2295, in expect

self.runCmd(

File ".../lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1998, in runCmd

self.assertTrue(self.res.Succeeded(),

AssertionError: False is not True : Command 'process launch
Error output:
error: failed to get reply to handshake packet within timeout of 0.0 seconds
' did not return successfully

Thanks for the notice. I was pretty sure it failed to me prior to my changes but it is possible that I read the output wrong, so I'm going to check it now.

I'm sorry, it is indeed my fault. I'm going to try to fix it shortly, and if I don't manage to figure it out, I'm going to revert this and the commits depending on it.

I've reverted the code changes and marked my new tests xfail. I will attempt to find the problem in the new code later. Once again, I'm sorry for missing this.

Ok, apparently the changes that's breaking this is replacing the OK response with l when there's no debugged process.