This is an ongoing series of commits that are reformatting our Python
code. Reformatting is done with `black` (23.1.0).
If you end up having problems merging this commit because you have made
changes to a python file, the best way to handle that is to run `git
checkout --ours <yourfile>` and then reformat it with black.
RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Differential revision: https://reviews.llvm.org/D151460
Improve handling of multiple successive continue packets in non-stop
mode. More specifically:
1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.
2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.
With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710
This reverts commit f8605da8758fbae16410e4ed5493a39429fd73ec.
This is causing buildbot failures and now I see that I have not updated
the tests to use "stop" instead of "trap".
Improve handling of multiple successive continue packets in non-stop
mode. More specifically:
1. Explicitly send error response (instead of crashing on assertion)
if the user attempts to resume the same process twice. Since we
do not support thread-level non-stop mode, one needs to always stop
the process explicitly before resuming another thread set.
2. Actually stop the process if "vCont;t" is delivered to a running
process. Similarly, we only support stopping all the running threads
simultaneously (via -1) and return an error in any other case.
With this patch, running multiple processes simultaneously is still
unsupported. The patch also employs a hack to avoid enabling stdio
forwarding on "vCont;t" packet. Both of these issues are addressed
by followup patches.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D128710
Perform a major refactoring of vCont-threads tests in order to attempt
to improve their stability and performance.
Split test_vCont_run_subset_of_threads() into smaller test cases,
and split the whole suite into two files: one for signal-related tests,
the running-subset-of tests.
Eliminate output_match checks entirely, as they are fragile to
fragmentation of output. Instead, for the initial thread list capture
raise an explicit SIGINT from inside the test program, and for
the remaining output let the test program run until exit, and check all
the captured output afterwards.
For resume tests, capture the LLDB's thread view before and after
starting new threads in order to determine the IDs corresponding
to subthreads rather than relying on program output for that.
Add a mutex for output to guarantee serialization. A barrier is used
to guarantee that all threads start before SIGINT, and an atomic bool
is used to delay prints from happening until after SIGINT.
Call std::this_thread::yield() to reduce the risk of one of the threads
not being run.
This fixes the test hangs on FreeBSD. Hopefully, it will also fix all
the flakiness on buildbots.
Thanks to Pavel Labath for figuring out why the original version did not
work on Debian.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D129012
Perform a major refactoring of vCont-threads tests in order to attempt
to improve their stability and performance.
Split test_vCont_run_subset_of_threads() into smaller test cases,
and split the whole suite into two files: one for signal-related tests,
the running-subset-of tests.
Eliminate output_match checks entirely, as they are fragile to
fragmentation of output. Instead, for the initial thread list capture
raise an explicit SIGSTOP from inside the test program, and for
the remaining output let the test program run until exit, and check all
the captured output afterwards.
For resume tests, capture the LLDB's thread view before and after
starting new threads in order to determine the IDs corresponding
to subthreads rather than relying on program output for that.
Add a mutex for output to guarantee serialization. A barrier is used
to guarantee that all threads start before SIGSTOP, and an atomic bool
is used to delay prints from happening until after SIGSTOP.
Call std::this_thread::yield() to reduce the risk of one of the threads
not being run.
This fixes the test hangs on FreeBSD. Hopefully, it will also fix all
the flakiness on buildbots.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D129012
