[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://r
[lldb][tests] Automatically call compute_mydir (NFC)Eliminate boilerplate of having each test manually assign to `mydir` by calling`compute_mydir` in lldbtest.py.Differential Revision: https://reviews.llvm.org/D128077
show more ...
Recommit [lldb/test] Make category-skipping logic "platform"-independentThis recommits dddf4ce03, which was reverted because of a couple of testfailures on macos. The reason behind the failures wa
Recommit [lldb/test] Make category-skipping logic "platform"-independentThis recommits dddf4ce03, which was reverted because of a couple of testfailures on macos. The reason behind the failures was that the patchinadvertenly changed the value returned by the host platform from"macosx" to "darwin". The new version fixes that.Original commit message was:The decision which categories are relevant for a particular test runhappen very early in the test setup process. They use the SBPlatformobject to determine which categories should be skipped. The platformobject created for this purpose transcends individual test runs.This setup is not compatible with the direction discussed in<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>-- when platform objects are tied to a specific (SB)Debugger, they needto be created alongside it, which currently happens in the test setUpmethod.This patch is the first step in that direction -- it rewrites thecategory skipping logic to avoid depending on a global SBPlatformobject. Fortunately, the skipping logic is fairly simple (and I believeit outght to stay that way) and mainly consists of comparing theplatform name against some hardcoded lists. This patch bases thiscomparison on the platform name instead of the os part of the triple (asreported by the platform).Differential Revision: https://reviews.llvm.org/D121605
[lldb] Replace asserts on .Success() with assertSuccess()Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).* `assertSuccess` prints out the error's message
[lldb] Replace asserts on .Success() with assertSuccess()Replace forms of `assertTrue(err.Success())` with `assertSuccess(err)` (added in D82759).* `assertSuccess` prints out the error's message* `assertSuccess` expresses explicit higher level semantics, both to the reader and for test failure output* `assertSuccess` seems not to be well known, using it where possible will help spread knowledge* `assertSuccess` statements are more succinctDifferential Revision: https://reviews.llvm.org/D119616
[lldb] fix -print-script-interpreter-info on windowsApparently "{sys.prefix}/bin/python3" isn't where you find thepython interpreter on windows, so the test I wrote for-print-script-interpreter-i
[lldb] fix -print-script-interpreter-info on windowsApparently "{sys.prefix}/bin/python3" isn't where you find thepython interpreter on windows, so the test I wrote for-print-script-interpreter-info is failing.We can't rely on sys.executable at runtime, because that will pointto lldb.exe not python.exe.We can't just record sys.executable from build time, because pythoncould have been moved to a different location.But it should be OK to apply relative path from sys.prefix to sys.executablefrom build-time to the sys.prefix at runtime.Reviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D113650
[lldb] temporarily disable TestPaths.test_interpreter_info on windowsI'm disabling this test until the fix is reviewed(here https://reviews.llvm.org/D113650/)
[lldb] make it easier to find LLDB's pythonIt is surprisingly difficult to write a simple python script thatcan reliably `import lldb` without failing, or crashing. I'mcurrently resorting to co
[lldb] make it easier to find LLDB's pythonIt is surprisingly difficult to write a simple python script thatcan reliably `import lldb` without failing, or crashing. I'mcurrently resorting to convolutions like this: def find_lldb(may_reexec=False): if prefix := os.environ.get('LLDB_PYTHON_PREFIX'): if os.path.realpath(prefix) != os.path.realpath(sys.prefix): raise Exception("cannot import lldb.\n" f" sys.prefix should be: {prefix}\n" f" but it is: {sys.prefix}") else: line1, line2 = subprocess.run( ['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'], encoding='utf8', stdout=subprocess.PIPE, check=True).stdout.strip().splitlines() assert line1.strip() == '(lldb) script print(sys.prefix)' prefix = line2.strip() os.environ['LLDB_PYTHON_PREFIX'] = prefix if sys.prefix != prefix: if not may_reexec: raise Exception( "cannot import lldb.\n" + f" This python, at {sys.prefix}\n" f" does not math LLDB's python at {prefix}") os.environ['LLDB_PYTHON_PREFIX'] = prefix python_exe = os.path.join(prefix, 'bin', 'python3') os.execl(python_exe, python_exe, *sys.argv) lldb_path = subprocess.run(['lldb', '-P'], check=True, stdout=subprocess.PIPE, encoding='utf8').stdout.strip() sys.path = [lldb_path] + sys.pathThis patch aims to replace all that with: #!/usr/bin/env lldb-python import lldb ...... by adding the following features:* new command line option: --print-script-interpreter-info. This prints language-specific information about the script interpreter in JSON format.* new tool (unix only): lldb-python which finds python and exec's it.Reviewed By: JDevlieghereDifferential Revision: https://reviews.llvm.org/D112973
[lldb] Fix shared library directory computation on windowsOur code for locating the shared library directory works via dladdr (orthe windows equivalent) to locate the path of an address known to r
[lldb] Fix shared library directory computation on windowsOur code for locating the shared library directory works via dladdr (orthe windows equivalent) to locate the path of an address known to residein liblldb. This works great for C++ programs, but there's a catch.When (lib)lldb is used from python (like in our test suite), this dladdrcall will return a path to the _lldb.so (or such) file in the pythondirectory. To compensate for this, we have code which attempts toresolve this symlink, to ensure we get the canonical location. However,here's the second catch.On windows, this file is not a symlink (but a copy), so this logicfails. Since most of our other paths are derived from the liblldblocation, all of these paths will be wrong, when running the test suite.One effect of this was the failure to find lldb-server in D96202.To fix this issue, I add some windows-specific code to locate theliblldb directory. Since it cannot rely on symlinks, it works bymanually walking the directory tree -- essentially doing the opposite ofwhat we do when computing the python directory.To avoid python leaking back into the host code, I implement this withthe help of a callback which can be passed to HostInfo::Initialize inorder to assist with the directory location. The callback lives insidethe python plugin.I also strenghten the existing path test to ensure the returned path isthe right one.Differential Revision: https://reviews.llvm.org/D96779
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdi
[lldb][test] Remove symlink for API tests.Summary: Moves lldbsuite tests to lldb/test/API.This is a largely mechanical change, moved with the following steps:```rm lldb/test/API/testcasesmkdir -p lldb/test/API/{test_runner/test,tools/lldb-{server,vscode}}mv lldb/packages/Python/lldbsuite/test/test_runner/test lldb/test/API/test_runnerfor d in $(find lldb/packages/Python/lldbsuite/test/* -maxdepth 0 -type d | egrep -v "make|plugins|test_runner|tools"); do mv $d lldb/test/API; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-vscode -maxdepth 1 -mindepth 1 | grep -v ".py"); do mv $d lldb/test/API/tools/lldb-vscode; donefor d in $(find lldb/packages/Python/lldbsuite/test/tools/lldb-server -maxdepth 1 -mindepth 1 | egrep -v "gdbremote_testcase.py|lldbgdbserverutils.py|socket_packet_pump.py"); do mv $d lldb/test/API/tools/lldb-server; done```lldb/packages/Python/lldbsuite/__init__.py and lldb/test/API/lit.cfg.py were also updated with the new directory structure.Reviewers: labath, JDevlieghereTags: #lldbDifferential Revision: https://reviews.llvm.org/D71151