From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id eTS4CbLv+GkGORMAWB0awg (envelope-from ) for ; Mon, 04 May 2026 15:12:50 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=O5pWP1rQ; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 23BB41E0BA; Mon, 04 May 2026 15:12:50 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 3423B1E067 for ; Mon, 04 May 2026 15:12:48 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 45F334BABF31 for ; Mon, 4 May 2026 19:12:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 45F334BABF31 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=O5pWP1rQ Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 9341F4BABF10 for ; Mon, 4 May 2026 19:12:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9341F4BABF10 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9341F4BABF10 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777921934; cv=none; b=bNY9j8tsa5aTksxDVWyq/2GnDp8i5WiZEcjtlGVmX1MXzivNTxiWJpuBELj/av6I41cY0hOvwagt4GeGK32DeYekhVNb9xmeCiu2JJL6XaKtAmb6JzdqQS7AgZFJE3z2hYUJdh54PT6Z0qdK47eoS0cAZ8WL3eYbs8Veli18hoI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1777921934; c=relaxed/simple; bh=DAXa5QQ01FObRZoc4fYgDysFA63o0egVHcNZwH8Ices=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=EvT+fkHC4+IDr8Uv5q46K9TZuVh4E2vm2g7JNocybwuMBy4koTDYqJkN6wGdqkDA/VvM5WhMO/FCsnHFXh8l3rX6tktKNGRPZyP+8hWBONLnwBwcnfFxtRqUAGIY2XBGfYxW9mxDdC+GSxEz7KLVpl/dDWPCv514Y/0+tpJGPhc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9341F4BABF10 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1wJyiE-0000am-0O; Mon, 04 May 2026 15:12:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/nHr7QUgQU4LKF387nOgNDdk6y+b+NyWE1YCXjwRAFg=; b=O5pWP1rQNUVj k0EHzcKuhYM4+IqNNwqBJ/JKWERKJpBc3E/XDYRo1VpCSN/zlQjtmyse5+fNQXD6lV5NdAuacDqTA mvsM6gjLPI1ed9eUCFP9ld9r6uWRkKVxIUF4ZdlF0Jn+nYKu5PMEbfUvsKkmm30SzG32LxDlHZMep YLKhRoA4d0sMTCAON/cukq+5ENLX8yEV8F/Tdup3xY17+kD6HRA36hpPfS64fbjvDkqS7/SYk5Wnl VAQbg7sybRGvNSVeA4NrWdo9a+knUXYLKacK8O/Hn1UrX1RKqszIJmUeAXHzZR3mz9RX3kLXd9Mi6 /k5fTpAILVXYHdZrUbFuhg==; Date: Mon, 04 May 2026 22:12:09 +0300 Message-Id: <867bpjc7li.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves Cc: gdb-patches@sourceware.org In-Reply-To: <20260504173344.1278735-2-pedro@palves.net> (message from Pedro Alves on Mon, 4 May 2026 18:33:40 +0100) Subject: Re: [PATCH 1/3] Windows gdb: Show CONTEXT_EXCEPTION_REQUEST info in "info threads" References: <20260504173344.1278735-1-pedro@palves.net> <20260504173344.1278735-2-pedro@palves.net> 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 > From: Pedro Alves > Date: Mon, 4 May 2026 18:33:40 +0100 > > This patch makes the Windows native target expose > CONTEXT_EXCEPTION_REQUEST 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). > > This is useful information to see, as system calls are not > interruptible on Windows. E.g. an infcall on a thread that is blocked > in a system call will appear to hang, until the system call returns on > its own. > > Change-Id: I04221f123eef81d59b5cc1c9fbb298f7a33fa001 > commit-id:d93544e4 > --- > gdb/nat/windows-nat.h | 3 ++- > gdb/windows-nat.c | 22 ++++++++++++++++++++++ > 2 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h > index 52378765438..d66d5ec0ed3 100644 > --- a/gdb/nat/windows-nat.h > +++ b/gdb/nat/windows-nat.h > @@ -527,7 +527,8 @@ struct WindowsContext > | CONTEXT_SEGMENTS > #endif > | CONTEXT_DEBUG_REGISTERS > - | CONTEXT_EXTENDED_REGISTERS); > + | CONTEXT_EXTENDED_REGISTERS > + | CONTEXT_EXCEPTION_REQUEST); > }; > > #ifdef __x86_64__ > diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c > index a9647e90bb8..d01fbc8e4ba 100644 > --- a/gdb/windows-nat.c > +++ b/gdb/windows-nat.c > @@ -3363,6 +3363,28 @@ windows_nat_target::extra_thread_info (thread_info *info) > || th->last_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT) > return "exiting process"; > > + /* Specifying CONTEXT_EXCEPTION_REQUEST in ContextFlags as input > + (which we do), asks Windows to report back why the thread entered > + kernel mode. If GetThreadContext returns a context with > + CONTEXT_EXCEPTION_REPORTING set, it means that it understood the > + request. */ > + windows_process->fill_thread_context (th); > + DWORD context_flags = *windows_process->context_flags_ptr (th); > + if ((context_flags & CONTEXT_EXCEPTION_REPORTING) != 0) > + { > + /* The thread was running user space code which raised an > + exception, which we intercepted. */ > + if ((context_flags & CONTEXT_EXCEPTION_ACTIVE) != 0) > + return "in exception"; > + > + /* The thread was running a system call. */ > + if ((context_flags & CONTEXT_SERVICE_ACTIVE) != 0) > + return "in syscall"; > + > + /* Otherwise, the thread was simply suspended while running > + user space code. */ > + } > + > return nullptr; > } The CONTEXT_* constants you are adding aren't defined in mingw.org's MinGW headers. I'm guessing they were introduced for Vista or something. So I think we will need to have their explicit definitions in nat/windows-nat.h, guarded with #ifndef. Also, this page: https://zachsaw.blogspot.com/2010/11/wow64-bug-getthreadcontext-may-return.html seems to say (near the end) that XP doesn't support CONTEXT_EXCEPTION_REQUEST, so maybe this feature should be guarded by a later Windows version, say 7 or 8.1?