[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.
Loading
Please register or sign in to comment