[all-commits] [llvm/llvm-project] 04b766: [lldb/test] Deflake TestGdbRemote_vContThreads eve...

[Pavel Labath via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 04b766dab0d9d786ab5695336348b0c01646cf99
      https://github.com/llvm/llvm-project/commit/04b766dab0d9d786ab5695336348b0c01646cf99
  Author: Pavel Labath <pavel at labath.sk>
  Date:   2021-03-30 (Tue, 30 Mar 2021)

  Changed paths:
    A lldb/packages/Python/lldbsuite/test/make/thread.h
    R lldb/test/API/tools/lldb-server/TestGdbRemote_vContThreads.py
    M lldb/test/API/tools/lldb-server/main.cpp
    A lldb/test/API/tools/lldb-server/vCont-threads/Makefile
    A lldb/test/API/tools/lldb-server/vCont-threads/TestGdbRemote_vContThreads.py
    A lldb/test/API/tools/lldb-server/vCont-threads/main.cpp

  Log Message:
  -----------
  [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.