[lldb/test] Deflake TestGdbRemote_vContThreads even more
authorPavel Labath <pavel@labath.sk>
Tue, 30 Mar 2021 14:50:04 +0000 (16:50 +0200)
committerPavel Labath <pavel@labath.sk>
Tue, 30 Mar 2021 15:03:14 +0000 (17:03 +0200)
commit04b766dab0d9d786ab5695336348b0c01646cf99
tree0cc10872dfc81e36af4900c7a07970ce65a323aa
parentbd334c790f2e43e72270b8044f08303e1c2f283b
[lldb/test] Deflake TestGdbRemote_vContThreads even more

This patch fixes an issue, where if the thread has a signal blocked when
we try to inject it into the process (via vCont), then instead of
executing straight away, the injected signal will trigger another stop
when the thread unblocks the signal.

As (linux) threads start their life with SIGUSR1 (among others)
disabled, and only enable it during initialization, injecting the signal
during this window did not behave as expected. The fix is to change the
test to ensure the signal gets injected with the signal unblocked.

The simplest way to do this was to write a dedicated inferior for this
test. I also created a new header to factor out the function retrieving
the (os-specific) thread id.
lldb/packages/Python/lldbsuite/test/make/thread.h [new file with mode: 0644]
lldb/test/API/tools/lldb-server/main.cpp
lldb/test/API/tools/lldb-server/vCont-threads/Makefile [new file with mode: 0644]
lldb/test/API/tools/lldb-server/vCont-threads/TestGdbRemote_vContThreads.py [moved from lldb/test/API/tools/lldb-server/TestGdbRemote_vContThreads.py with 98% similarity]
lldb/test/API/tools/lldb-server/vCont-threads/main.cpp [new file with mode: 0644]