This is an archive of the discontinued LLVM Phabricator instance.

[lldb] [llgs] Support "t" vCont action
ClosedPublic

Authored by mgorny on Jun 3 2022, 11:24 AM.

Details

Summary

Implement support for the "t" action that is used to stop a thread.
Normally this action is used only in non-stop mode. However, there's
no technical reason why it couldn't be also used in all-stop mode,
e.g. to express "resume all threads except ..." (t:...;c).

While at it, add a more complete test for vCont correctly resuming
a subset of program's threads.

Sponsored by: The FreeBSD Foundation

Diff Detail

Event Timeline

mgorny created this revision.Jun 3 2022, 11:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 3 2022, 11:24 AM
Herald added a subscriber: arichardson. · View Herald Transcript
mgorny requested review of this revision.Jun 3 2022, 11:24 AM
labath accepted this revision.Jun 19 2022, 11:57 PM
This revision is now accepted and ready to land.Jun 19 2022, 11:57 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 8:34 AM
mib added a subscriber: mib.Jun 27 2022, 6:08 PM

Hey @mgorny,

This patch is causing a test to fail on the macOS bot:
https://green.lab.llvm.org/green/job/lldb-cmake/44921/consoleText

Feel free to skip it or let me know if you need help reproducing the issue.

FAIL: lldb-api :: tools/lldb-server/TestGdbRemote_vCont.py (734 of 1734)
******************** TEST 'lldb-api :: tools/lldb-server/TestGdbRemote_vCont.py' FAILED ********************
FAIL: LLDB (/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-x86_64) :: test_vCont_supports_t_debugserver (TestGdbRemote_vCont.TestGdbRemote_vCont)
UNSUPPORTED: LLDB (/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang-x86_64) :: test_vCont_supports_t_llgs (TestGdbRemote_vCont.TestGdbRemote_vCont) (test case does not fall in any category of interest for this run) 
Restore dir to: /Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/tools/lldb/test
======================================================================
FAIL: test_vCont_supports_t_debugserver (TestGdbRemote_vCont.TestGdbRemote_vCont)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 52, in test_method
    return attrvalue(self)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/tools/lldb-server/TestGdbRemote_vCont.py", line 44, in test_vCont_supports_t
    self.vCont_supports_mode("t")
  File "/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/lldb/test/API/tools/lldb-server/TestGdbRemote_vCont.py", line 23, in vCont_supports_mode
    self.assertIn(mode, supported_vCont_modes)
AssertionError: 't' not found in {'c': 1, 'C': 1, 's': 1, 'S': 1}
Config=x86_64-/Users/buildslave/jenkins/workspace/lldb-cmake/lldb-build/bin/clang
----------------------------------------------------------------------
Ran 14 tests in 17.353s

RESULT: FAILED (6 passes, 1 failures, 0 errors, 7 skipped, 0 expected failures, 0 unexpected successes)

Thanks, I've pushed a skip. I'm sorry, I keep forgetting to mark these new tests llgs-only :-(.

mgorny added a comment.Jul 1 2022, 6:40 AM

That's so rare it's going to be hard figuring out if any changes actually fix it. My only idea is to either increase the sleep within continue_and_get_threads_running() or make output inside the process more frequent — though the latter probably won't help if some threads don't get run because of loaded system.

labath added a comment.Jul 1 2022, 6:49 AM

That's so rare it's going to be hard figuring out if any changes actually fix it. My only idea is to either increase the sleep within continue_and_get_threads_running() or make output inside the process more frequent — though the latter probably won't help if some threads don't get run because of loaded system.

Don't we have the ability to wait for a specific output from the process? Could we make use of that to await for the actual "thread is running" message? If needed, we can put some barriers between the print calls, and then we can even make sure each thread prints its message exactly once.

mgorny added a comment.Jul 1 2022, 7:20 AM

I don't think we can reliably check whether additional threads aren't run then.

I have another idea that could work better if we could assume that the scheduler runs threads of the same process somehow evenly — or well, I suppose it'd be better in any case. Rather than stopping the process from LLDB, I could add a counter that issues SIGSTOP from inside the process after doing N (say, 5) prints. I suppose that should give it enough time for all threads to output something.

Just need to figure out a simple synchronization method to ensure that SIGSTOP is emitted only once.

mgorny added a comment.Jul 1 2022, 7:46 AM

Don't we have the ability to wait for a specific output from the process?

Hmm, actually thinking about it, I suppose we could wait for m*n messages from m threads (say, n=5) and then we should have a pretty good chance that if an extra thread is running, it would fit somewhere between them.

mgorny added a comment.Jul 1 2022, 8:13 AM

Unfortunately, switching to output_match makes the test even more flaky. I think it doesn't handle it well if two output lines get sent as a single packet.

That said, the other tests are probably flaky the other way — they rely on all signals being reported in a single output packet.

I'm going to continue trying to improve the test.