<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in Makefile</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>04b766da - [lldb/test] Deflake TestGdbRemote_vContThreads even more</title>
        <link>http://172.16.0.5:8080/history/llvm-project-15.0.7/lldb/test/API/tools/lldb-server/vCont-threads/Makefile#04b766da</link>
        <description>[lldb/test] Deflake TestGdbRemote_vContThreads even moreThis patch fixes an issue, where if the thread has a signal blocked whenwe try to inject it into the process (via vCont), then instead ofexecuting straight away, the injected signal will trigger another stopwhen the thread unblocks the signal.As (linux) threads start their life with SIGUSR1 (among others)disabled, and only enable it during initialization, injecting the signalduring this window did not behave as expected. The fix is to change thetest to ensure the signal gets injected with the signal unblocked.The simplest way to do this was to write a dedicated inferior for thistest. I also created a new header to factor out the function retrievingthe (os-specific) thread id.

            List of files:
            /llvm-project-15.0.7/lldb/test/API/tools/lldb-server/vCont-threads/Makefile</description>
        <pubDate>Tue, 30 Mar 2021 14:50:04 +0000</pubDate>
        <dc:creator>Pavel Labath &lt;pavel@labath.sk&gt;</dc:creator>
    </item>
</channel>
</rss>
