aa07282a25
This test has been flaky lately (https://github.com/llvm/llvm-project/issues/101162) and I disabled it everywhere initially. I found that it always uses "x86_64" for the program architecture so the test was "passing" elsewhere but I don't think it was meant to. So I have added a define to pass on the host's architecture when compiling. This makes it work on AArch64 as well. While I'm here I've fixed the uint64_t formatting warnings by using the defined formats that'll work everywhere. In addition, I found that the function names include "()" on Linux, so now we check for "foo" or "foo()". The test cpp file has never been, or was only partially formatted so I've not formatted the changes, just kept to the local style. I've removed the Linux skip to see if any of this helps the timeouts, and to verify the build command changes. If the timeouts come back I'll disable it again.
36 lines
1.3 KiB
Python
36 lines
1.3 KiB
Python
"""Test the lldb public C++ api when doing multiple debug sessions simultaneously."""
|
|
|
|
import os
|
|
import subprocess
|
|
|
|
import lldb
|
|
from lldbsuite.test.decorators import *
|
|
from lldbsuite.test.lldbtest import *
|
|
from lldbsuite.test import lldbutil
|
|
|
|
|
|
class TestMultipleSimultaneousDebuggers(TestBase):
|
|
NO_DEBUG_INFO_TESTCASE = True
|
|
|
|
# Sometimes times out on Linux, see https://github.com/llvm/llvm-project/issues/101162.
|
|
@skipIfNoSBHeaders
|
|
@skipIfWindows
|
|
@skipIfHostIncompatibleWithTarget
|
|
def test_multiple_debuggers(self):
|
|
self.driver_exe = self.getBuildArtifact("multi-process-driver")
|
|
self.buildDriver(
|
|
"multi-process-driver.cpp",
|
|
self.driver_exe,
|
|
defines=[("LLDB_HOST_ARCH", lldbplatformutil.getArchitecture())],
|
|
)
|
|
self.addTearDownHook(lambda: os.remove(self.driver_exe))
|
|
|
|
self.inferior_exe = self.getBuildArtifact("testprog")
|
|
self.buildDriver("testprog.cpp", self.inferior_exe)
|
|
self.addTearDownHook(lambda: os.remove(self.inferior_exe))
|
|
|
|
# check_call will raise a CalledProcessError if the executable doesn't
|
|
# return exit code 0 to indicate success. We can let this exception go
|
|
# - the test harness will recognize it as a test failure.
|
|
subprocess.check_call([self.driver_exe, self.inferior_exe])
|