When OS plugins are present, it can be helpful to query information about the backing thread behind an OS thread, if it exists. There is no mechanism to do so prior to this commit. As a first step, this commit enhances `thread info` with a `--backing-thread` flag, causing the command to use the backing thread of the selected thread, if it exists.
These prevented ThreadMemory from correctly returning the Name/Queue/Info of the backing thread. Note about testing: this test only finds regressions if the system sets a name or queue for the backing thread. While this may not be true everywhere, it still provides coverage in some systems, e.g. in Apple platforms.
In the presence of OS plugins, StopInfoMachException currently propagates breakpoint stop reasons even if those breakpoints were not intended for a specific thread, effectively removing our ability to set thread-specific breakpoints. This was originally added in [1], but the motivation provided in the comment does not seem strong enough to remove the ability to set thread-specific breakpoints. The only way to break thread specific breakpoints would be if a user set such a breakpoint and _then_ loaded an OS plugin, a scenario which we would likely not want to support. [1]: https://github.com/swiftlang/llvm-project/commit/ab745c2ad865c07f3905482fd071ef36c024713a#diff-8ec6e41b1dffa7ac4b5841aae24d66442ef7ebc62c8618f89354d84594f91050R501
This fixes a regression caused by my commit where I added test as skipped using a decorator but forgot to add import decorator in TestPythonOSPlugin.py
test_run_python_os_step in TestPythonOSPlugin.py fails on Windows after PR #97043. The test passes when run individually using dotest.py. I have marked this skipped for windows to make LLDB AArch64 Windows buildbot happy. https://github.com/llvm/llvm-project/commit/a4c18137d84bc48df49ee0101bef465a955e62ac https://lab.llvm.org/buildbot/#/builders/141/builds/379
In one of my recent PRs I mistakenly had two test-cases with the same
name, preventing one of them to run. Since it's an easy mistake to make
(e.g., copy pasting existing test-cases), I ran following sanity-check
script over `lldb/test/API`, which found couple of tests which were
losing coverage because of this (or in some cases simply had duplicate
tests):
```
import ast
import sys
filename = sys.argv[1]
print(f'Checking {filename}...')
tree = ast.parse(open(filename, 'r').read())
for node in ast.walk(tree):
if not isinstance(node, ast.ClassDef):
continue
func_names = []
for child in ast.iter_child_nodes(node):
if isinstance(child, ast.FunctionDef):
func_names.append(child.name)
seen_func_names = set()
duplicate_func_names = []
for name in func_names:
if name in seen_func_names:
duplicate_func_names.append(name)
else:
seen_func_names.add(name)
if len(duplicate_func_names) != 0:
print(f'Multiple func names found:\n\t{duplicate_func_names}\n\tclass {node.name}\n\tfile: {filename}')
```
This patch fixes these cases.
assertEquals is a deprecated alias for assertEqual and has been removed in Python 3.12. This wasn't an issue previously because we used a vendored version of the unittest module. Now that we use the built-in version this gets updated together with the Python version used to run the test suite.
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
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
Follow up to D95813, this converts multiline assertTrue to assertEqual. Differential Revision: https://reviews.llvm.org/D95899