From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id rwGrDZrY+GkpGRMAWB0awg (envelope-from ) for ; Mon, 04 May 2026 13:34:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 243221E067; Mon, 04 May 2026 13:34:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id ACDDD1E067 for ; Mon, 04 May 2026 13:34:15 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id DDFB54B99F4A for ; Mon, 4 May 2026 17:34:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DDFB54B99F4A Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by sourceware.org (Postfix) with ESMTPS id 2BFDA4BABF1A for ; Mon, 4 May 2026 17:33:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2BFDA4BABF1A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2BFDA4BABF1A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777916031; cv=none; b=tmI5c0RHXewqZuhIYJRFEsKwcHBrVth78Nlw3H9pPCUHYoYJ6EhBffItvpXhXjJPOCKkUb8JyQJcFtJDHOXpmVOMvIayG1zfXw8AQ/NM+TQ8V6ymS8bhMqFsE6baS4Ljep6JgXi0gFpKtj8VuO3jpDt/YClGAPxceNBsqeaFerw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777916031; c=relaxed/simple; bh=S8S6Yuq/rQJeWM0POpaiW0C6GI6Z2engpuBdKuc7PJc=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=na0tCBqs/QB4FqPR+h5YmJHJQVPRzo1s9r/syTLPIJjm/thNwtT56kL+y05giMnMG5JkeOqs2CDL9UZRSwZi/He/UQlo9PjpgO7i1QIVQ6M6dGI07MVGzzgxkaE8iRNAEqSlWTWzwY3GI6ISN8iGgglax9DrXilWov175OBy4SY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2BFDA4BABF1A Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-488a88aeec9so49155335e9.2 for ; Mon, 04 May 2026 10:33:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777916029; x=1778520829; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7MZ4JInvGyVaaSro3MszGPrRS1tg6cCCtR51EBS4Npk=; b=RiHXKQCeSMiVgk6u5i+SjuORPf/lk5pNGNbsGChlI5YZJoeR+Q8rworkV2OPh9KhNn Wp+lMG5n6Kz1dEJ64Liu1wG5ARPXwSPAljyGcvFcnudjvGvj6Zqh4JMNaw0W8NKr2XcP 9muBJszEnumDFBEDGt04DdPVx4vGklRimfA7KXH/+VSD2vH7dohGYLfzLoFomecbnY0Q FhP/0HnkDSl5hrqTfdLi21jjdF3w1oWOVSSaVyLL9LIGjqYks91//ww6C+f6lW7iTQ8o UJGjX9OJzwTD3lGj6MI0jBpq0xb+rYvVBUWgV1/zMTc6r3O0tSf4eYFt3nHpYqe4V6ch w6Kw== X-Gm-Message-State: AOJu0YwmbIA1SMrPBVst9cdid/MRvkWaZFB2XfGnGkXh6FqGGCPMQO4c EahV9mY44x+OxuLOMhuwJYBK1RyNBALb+wh69AEjmOTh49Mf+FJDoH7y4z6h2A== X-Gm-Gg: AeBDiev+tjQ6JNxcXhnrNHRFp3bRVrdmZ6C9od8ZjfSiK4UV66bQvKY2rQQOJQIiuNo BNoxi02Z96WXIeuPgPQjn3u5tEGh80f7x1tRBWrNFC8FjEyPa773RTicjlLOSxQqVaxaanhVw/n aXxVC2zVBUITnN1xjhq5/u4tA02StiIw2w7808H2JgHRz/YDc0p+INppEjptyZvpGGISQ798hyL /h8VoEjETpeOqUi97ILeASskLiz3gRFalof8M2n0EnwRItubSf8E8E19wlUxkqZ7mqgqGPl27su 79Ow4OB1wL827ubCppu46Kz6kDQrJ0OevEPzLr+3RkZw8eswkMqOK2B3Ig8PHA4KeJPiPtZqkeS OoRl2swU9qdvH+Yc+phQ0m9M6u5GVy8vChNxWuMnXvRcfLQIETpLZWtMUfDpj7DPerzhVUKrxff IoMVg/TNNNPQSvTN9YfNKUzrWWnSOTBYRK8cxz8HGk3SE= X-Received: by 2002:a05:600c:a411:b0:48a:7b55:12a6 with SMTP id 5b1f17b1804b1-48a980fc3e7mr126828365e9.0.1777916029095; Mon, 04 May 2026 10:33:49 -0700 (PDT) Received: from localhost ([2001:8a0:facb:a800:f625:f0b7:9de7:360b]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-48a8feefa72sm86278125e9.28.2026.05.04.10.33.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 May 2026 10:33:48 -0700 (PDT) From: Pedro Alves To: gdb-patches@sourceware.org Subject: [PATCH 0/3] Show CONTEXT_EXCEPTION_REQUEST info in "info threads" Date: Mon, 4 May 2026 18:33:39 +0100 Message-ID: <20260504173344.1278735-1-pedro@palves.net> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org While looking at gdb.threads/hand-call-in-threads.exp failures on Cygwin, I noticed that on Windows, if you do an infcall on a thread that is currently blocked in a syscall (e.g., on ntdll!ZwWaitForMultipleObjects), the infcall will hang (won't really run) until the thread returns from the system call on its own. On Linux, most system calls are interruptible, so you won't see this happening. On Windows however, system calls are NOT interruptible. If you pause the hung thread with Ctrl-C, you'll see that its (user space) PC won't have changed, still pointing to the entry to the function GDB wants to call. For example (with a simple program that just calls sleep in the main thread): ... (gdb) t 2 [Switching to thread 2 (Thread 15648.0x3d58)] #0 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll (gdb) p malloc(0) * hang, press ctrl-c * [New Thread 15648.0x12d4 (id 8)] Thread 8 received signal SIGINT, Interrupt. [Switching to Thread 15648.0x12d4] 0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll ❌️ The program received a signal in another thread while making a function call from GDB. Evaluation of the expression containing the function (malloc(size_t)) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) info threads Id Target Id Frame 1 Thread 15648.0x4338 "sleeper" main () at sleeper.c:5 2 Thread 15648.0x3d58 malloc (size=0) at /usr/src/debug/cygwin-3.6.3-1/winsup/cygwin/mm/malloc_wrapper.cc:85 3 Thread 15648.0x27e0 "sig" 0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll 4 Thread 15648.0x26f0 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll 6 Thread 15648.0x49f0 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll 7 Thread 15648.0x23b0 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll * 8 Thread 15648.0x12d4 0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll Now, I remembered from reading about SuspendThread and GetThreadContext woes early on while working in the non-stop support, that there was a way to tell whether the interrupted thread was running kernel or user space code. After digging through my bookmarks, I found it. It's explained here, in a comment from 2014 on a blog from 2010: https://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html#c5639760895973344002 Other places around the interwebs that I found with CONTEXT_EXCEPTION_REQUEST references all pointed to that sole comment... Microsoft doesn't document these flags, AFAICT, other than a brief mention here: https://learn.microsoft.com/en-us/windows/win32/debug/working-with-xstate-context Still, even Wine supports this, and MinGW headers define the constants. This series makes the Windows native target expose that information in "info threads" extra info, like so: (gdb) info threads Id Target Id Frame 1 Thread 15648.0x4338 "sleeper" main () at sleeper.c:5 2 Thread 15648.0x3d58 (in syscall) 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll 3 Thread 15648.0x27e0 "sig" (in syscall) 0x00007ffde3701bc4 in ntdll!ZwReadFile () from C:/WINDOWS/SYSTEM32/ntdll.dll 4 Thread 15648.0x26f0 (in syscall) 0x00007ffde37057b4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/WINDOWS/SYSTEM32/ntdll.dll * 5 Thread 15648.0xff8 (in exception) 0x00007ffde00aa464 in KERNELBASE!CtrlRoutine () from C:/WINDOWS/System32/KERNELBASE.dll (gdb) Above, we can see that thread 1 is running user space code, threads 2 to 4 are in some system call, and thread 5 raised an exception (a Ctrl-C). I could imagine us adding a warning whenever GDB changes register contents or does an infcall on a thread blocked inside a syscall, or something like that. But for now, I'm happy with at least seeing the info. For gdb.threads/hand-call-in-threads.exp at least, the testcase runs the infcall on the wrong thread, leading to the hang situation. Many testcases assume that threads 2 and above are the that that test program spawns, which is incorrect on Windows -- the Cygwin runtime and Windows spawn a few helper threads, so test program threads start at 4 or 5. The runtime threads are usually blocked inside a system call, so doing an infcall on them will hang. FWIW, I tried the same situation with Visual Studio, and it doesn't prevent evaluating the expression -- a dialog pops up saying something like "evaluating expression", and then after a few seconds it aborts it. We already support timing out of infcalls nowadays, except we default to an infinite timeout, so we're mostly covered. Pedro Alves (3): Windows gdb: Show CONTEXT_EXCEPTION_REQUEST info in "info threads" gdb manual: Cygwin => Windows Windows gdb: Document "info threads" Windows specifics gdb/doc/gdb.texinfo | 67 ++++++++++++++++++++++++++++++------------- gdb/nat/windows-nat.h | 3 +- gdb/windows-nat.c | 22 ++++++++++++++ 3 files changed, 71 insertions(+), 21 deletions(-) base-commit: 8c0ac471835ec86a67c5b42713d9f138f31e4014 -- 2.53.0