diff mbox

Program-assigned thread names on Windows

Message ID 5052d495-ea40-b364-96ea-9e68c90bd747@gmail.com
State New, archived
Headers

Commit Message

LRN July 23, 2016, 9:25 a.m. UTC 
  The attached patch adds thread naming support on Windows.

This works as documented[1] on MSDN - by catching a specific
exception that the program throws.

Setting thread name this way is supported by glib[2] and winpthreads[3] at
least, as well as any program developed with MS toolchain (because WinDbg
supported this for a long time).

[1] https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
[2]
https://git.gnome.org/browse/glib/commit/glib/gthread-win32.c?id=e118856430a798bbc529691ad235fd0b0684439d
[3]
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d95c795b44b76e1b60dfc119fd93cfd0cb35816/

Comments

Eli Zaretskii July 23, 2016, 9:33 a.m. UTC | #1 
> From: LRN <lrn1986@gmail.com>
> Date: Sat, 23 Jul 2016 12:25:15 +0300
> 
> The attached patch adds thread naming support on Windows.
> 
> This works as documented[1] on MSDN - by catching a specific
> exception that the program throws.
> 
> Setting thread name this way is supported by glib[2] and winpthreads[3] at
> least, as well as any program developed with MS toolchain (because WinDbg
> supported this for a long time).
> 
> [1] https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
> [2]
> https://git.gnome.org/browse/glib/commit/glib/gthread-win32.c?id=e118856430a798bbc529691ad235fd0b0684439d
> [3]
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d95c795b44b76e1b60dfc119fd93cfd0cb35816/

Thanks.  But I don't think what that means in terms of the "thread
name", "thread find", and "info threads" commands in GDB.  Can you
tell?
LRN July 23, 2016, 9:43 a.m. UTC | #2 
On 23.07.2016 12:33, Eli Zaretskii wrote:
> On 23.07.2016 12:25, LRN wrote:
>> The attached patch adds thread naming support on Windows.
>> 
>> This works as documented[1] on MSDN - by catching a specific
>> exception that the program throws.
>> 
>> Setting thread name this way is supported by glib[2] and winpthreads[3] at
>> least, as well as any program developed with MS toolchain (because WinDbg
>> supported this for a long time).
>> 
>> [1] https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
>> [2] https://git.gnome.org/browse/glib/commit/glib/gthread-
>> win32.c?id=e118856430a798bbc529691ad235fd0b0684439d
>> [3] https://sourceforge.net/p/mingw-w64/mingw-w64/ci
>> /0d95c795b44b76e1b60dfc119fd93cfd0cb35816/
>> 
> 
> Thanks.  But I don't think what that means in terms of the "thread
> name", "thread find", and "info threads" commands in GDB.  Can you
> tell?
> 

"info thread" will show the thread name, if it is set

"thread name" will change the thread name (but the debugee will not be
aware of that; i haven't looked for a way to communicate name change
back to the debugee, and i doubt that such way exists)

"thread find" will be able to find threads by their name, if they have it set
Eli Zaretskii July 23, 2016, 10:18 a.m. UTC | #3 
> From: LRN <lrn1986@gmail.com>
> Date: Sat, 23 Jul 2016 12:43:05 +0300
> 
> "info thread" will show the thread name, if it is set
> 
> "thread name" will change the thread name (but the debugee will not be
> aware of that; i haven't looked for a way to communicate name change
> back to the debugee, and i doubt that such way exists)
> 
> "thread find" will be able to find threads by their name, if they have it set

Sounds useful, thanks.
John Baldwin July 23, 2016, 4:39 p.m. UTC | #4 
On Saturday, July 23, 2016 12:25:15 PM LRN wrote:
> The attached patch adds thread naming support on Windows.
> 
> This works as documented[1] on MSDN - by catching a specific
> exception that the program throws.
> 
> Setting thread name this way is supported by glib[2] and winpthreads[3] at
> least, as well as any program developed with MS toolchain (because WinDbg
> supported this for a long time).
> 
> [1] https://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
> [2]
> https://git.gnome.org/browse/glib/commit/glib/gthread-win32.c?id=e118856430a798bbc529691ad235fd0b0684439d
> [3]
> https://sourceforge.net/p/mingw-w64/mingw-w64/ci/0d95c795b44b76e1b60dfc119fd93cfd0cb35816/

Does this leak 'thread_name' if the first character is '\0'?

+         thread_name = NULL;
+         if (!target_read_string ((CORE_ADDR) thread_name_target, &thread_name, 1024, 0)
+             || !thread_name || !*thread_name)
+           /* nothing to do */;
+         else
+           {
+             xfree (named_thread->name);
+             named_thread->name = thread_name;
+           }
+         result = 2;

Maybe restructure as:

    if (target_read_string (...))
      {
        if (thread_name && thread_name[0] != '\0')
          {
            xfree (named_thread->name);
            named_thread->name = thread_name;
          }
        else
          xfree (thread_name);
      }
diff mbox

Patch

diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 3f67486..01e7954 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -174,6 +174,9 @@  static int debug_registers_used;
 static int windows_initialization_done;
 #define DR6_CLEAR_VALUE 0xffff0ff0
 
+#define WINDOWS_THREADNAME_EXCEPTION 0x406D1388
+#define WINDOWS_THREADNAME_EXCEPTION_S "0x406D1388"
+
 /* The string sent by cygwin when it processes a signal.
    FIXME: This should be in a cygwin include file.  */
 #ifndef _CYGWIN_SIGNAL_STRING
@@ -1035,6 +1038,7 @@  static int
 handle_exception (struct target_waitstatus *ourstatus)
 {
   DWORD code = current_event.u.Exception.ExceptionRecord.ExceptionCode;
+  int result = 1;
 
   ourstatus->kind = TARGET_WAITKIND_STOPPED;
 
@@ -1140,6 +1144,38 @@  handle_exception (struct target_waitstatus *ourstatus)
       DEBUG_EXCEPTION_SIMPLE ("EXCEPTION_NONCONTINUABLE_EXCEPTION");
       ourstatus->value.sig = GDB_SIGNAL_ILL;
       break;
+    case WINDOWS_THREADNAME_EXCEPTION:
+      DEBUG_EXCEPTION_SIMPLE (WINDOWS_THREADNAME_EXCEPTION_S);
+      ourstatus->value.sig = GDB_SIGNAL_TRAP;
+      if (current_event.u.Exception.ExceptionRecord.NumberParameters == 4)
+	{
+	  DWORD named_thread_id;
+	  ptid_t named_thread_ptid;
+	  struct thread_info *named_thread;
+	  uintptr_t thread_name_target;
+	  char *thread_name;
+
+	  named_thread_id = (DWORD) current_event.u.Exception.ExceptionRecord.ExceptionInformation[2];
+	  thread_name_target = (uintptr_t) current_event.u.Exception.ExceptionRecord.ExceptionInformation[1];
+
+	  if (named_thread_id == (DWORD) -1)
+	    named_thread_id = current_event.dwThreadId;
+
+	  named_thread_ptid = ptid_build (current_event.dwProcessId, 0, named_thread_id),
+	  named_thread = find_thread_ptid (named_thread_ptid);
+
+	  thread_name = NULL;
+	  if (!target_read_string ((CORE_ADDR) thread_name_target, &thread_name, 1024, 0)
+	      || !thread_name || !*thread_name)
+	    /* nothing to do */;
+	  else
+	    {
+	      xfree (named_thread->name);
+	      named_thread->name = thread_name;
+	    }
+	  result = 2;
+	}
+      break;
     default:
       /* Treat unhandled first chance exceptions specially.  */
       if (current_event.u.Exception.dwFirstChance)
@@ -1153,7 +1189,7 @@  handle_exception (struct target_waitstatus *ourstatus)
     }
   exception_count++;
   last_sig = ourstatus->value.sig;
-  return 1;
+  return result;
 }
 
 /* Resume thread specified by ID, or all artificially suspended
@@ -1510,10 +1546,19 @@  get_windows_debug_event (struct target_ops *ops,
 		     "EXCEPTION_DEBUG_EVENT"));
       if (saw_create != 1)
 	break;
-      if (handle_exception (ourstatus))
-	thread_id = current_event.dwThreadId;
-      else
-	continue_status = DBG_EXCEPTION_NOT_HANDLED;
+      switch (handle_exception (ourstatus))
+	{
+	case 0:
+	default:
+	  continue_status = DBG_EXCEPTION_NOT_HANDLED;
+	  break;
+	case 1:
+	  thread_id = current_event.dwThreadId;
+	  break;
+	case 2:
+	  continue_status = DBG_CONTINUE;
+	  break;
+	}
       break;
 
     case OUTPUT_DEBUG_STRING_EVENT:	/* Message from the kernel.  */