From: Pedro Alves <pedro@palves.net>
Date: Mon, 12 Jun 2023 18:07:30 +0000 (+0100)
Subject: Show CONTEXT_EXCEPTION_REQUEST info in "info threads" (submit separately) (WIP)
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7194a987a6bf428d9ebffbe3069b73c67896406e;p=thirdparty%2Fbinutils-gdb.git

Show CONTEXT_EXCEPTION_REQUEST info in "info threads" (submit separately) (WIP)

document CONTEXT_EXCEPTION_REQUEST / CONTEXT_EXCEPTION_REPORTING /
   CONTEXT_EXCEPTION_ACTIVE / CONTEXT_SERVICE_ACTIVE.

    "so interesting... so I've been looking at only remaining testsuite
    hang that I saw in my last testsuite run.  it's a test that enables
    schedlock, and then calls a function in each thread in the program.
    on cygwin, the infcalls hang, and things break down such that the
    testcase ends up hanging forever.  back to the infcall hanging -- the
    issue is calling a function in a thread that is currently running
    kernel code.  on linux, most system calls are interruptible, and then
    syscall restart is a thing.  on Windows, system calls are NOT
    interruptible.  The threads in question in the testcase are stopped
    inside the syscall done by ntdll!ZwWaitForMultipleObjects .  I can
    pause the hung thread with ctrl-c, and its (userspace) PC won't have
    changed, still pointing to the entry to the function GDB wants to
    call.  Now, I remembered from reading about SuspendThread and
    GetThreadContext woes that there was a way to tell whether the
    interrupted thread was running kernel or userspace 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 see with
    CONTEXT_EXCEPTION_REQUEST references all point to that sole comment...
    Microsoft doesn't document these flags, AFAICT.  Kind of funny.

    not sure what to do with that.  Maybe we could add a warning whenever
    GDB changes register contents of a thread blocked inside a syscall.
    For now, I'll just see if I can avoid the issue / hang in the test
    itself.

    "interesting -- I tried the same 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, with the result being the above.

     a time out for function calls sounds like a good idea to me.  I
     think lldb has one."

   At:
     https://learn.microsoft.com/en-us/visualstudio/debugger/error-evaluating-the-function-function-timed-out-and-needed-to-be-aborted-in-an-unsafe-way?view=vs-2022

     "One common reason for this problem is that when the debugger
     evaluates a property, it only allows the thread being inspected to
     execute. So if the property is waiting on other threads to run
     inside the debugged application, and if it is waiting in a way that
     the .NET Runtime isn't able to interrupt, this problem will
     happen."

Change-Id: I04221f123eef81d59b5cc1c9fbb298f7a33fa001
---

diff --git a/gdb/nat/windows-nat.h b/gdb/nat/windows-nat.h
index 568c7c46a51..2d3fc3f8531 100644
--- a/gdb/nat/windows-nat.h
+++ b/gdb/nat/windows-nat.h
@@ -524,7 +524,9 @@ struct WindowsContext<CONTEXT *>
 				     | CONTEXT_FLOATING_POINT
 				     | CONTEXT_SEGMENTS
 				     | CONTEXT_DEBUG_REGISTERS
-				     | CONTEXT_EXTENDED_REGISTERS);
+				     | CONTEXT_EXTENDED_REGISTERS
+				     /* What about WoW64? */
+				     | CONTEXT_EXCEPTION_REQUEST);
 };
 
 #ifdef __x86_64__
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 827f342f7fb..60521e60a8d 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -4110,6 +4110,17 @@ windows_nat_target::extra_thread_info (thread_info *info)
 	   || th->last_event.dwDebugEventCode == EXIT_PROCESS_DEBUG_EVENT)
     return "exiting process";
 
+  /* FIXME: Wow64? */
+  windows_process.fill_thread_context (th);
+
+  if ((th->context.ContextFlags & CONTEXT_EXCEPTION_REPORTING) != 0)
+    {
+      if ((th->context.ContextFlags & CONTEXT_EXCEPTION_ACTIVE) != 0)
+	return "in exception";
+      if ((th->context.ContextFlags & CONTEXT_SERVICE_ACTIVE) != 0)
+	return "in kernel";
+    }
+
   return nullptr;
 }