From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41493 invoked by alias); 25 Jul 2016 12:17:54 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 41478 invoked by uid 89); 25 Jul 2016 12:17:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=H*M:1eb0, improperly, exceeds, Hx-spam-relays-external:ESMTPA X-HELO: out5-smtp.messagingengine.com Received: from out5-smtp.messagingengine.com (HELO out5-smtp.messagingengine.com) (66.111.4.29) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 25 Jul 2016 12:17:43 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 82C02204DB; Mon, 25 Jul 2016 08:17:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 25 Jul 2016 08:17:41 -0400 Received: from [192.168.1.102] (host86-179-112-245.range86-179.btcentralplus.com [86.179.112.245]) by mail.messagingengine.com (Postfix) with ESMTPA id 03F6AF29F5; Mon, 25 Jul 2016 08:17:40 -0400 (EDT) Subject: Re: Program-assigned thread names on Windows References: <5052d495-ea40-b364-96ea-9e68c90bd747@gmail.com> <14995502.J10EtrK3xV@ralph.baldwin.cx> <6a3446f9-63dc-67a1-3702-203d77c8d85d@gmail.com> From: Jon Turney Cc: LRN To: gdb-patches@sourceware.org Message-ID: Date: Mon, 25 Jul 2016 12:17:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6a3446f9-63dc-67a1-3702-203d77c8d85d@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-07/txt/msg00326.txt.bz2 On 23/07/2016 18:01, LRN wrote: > On 23.07.2016 19:39, John Baldwin wrote: >> > On Saturday, July 23, 2016 12:25:15 PM LRN wrote: >>> >> The attached patch adds thread naming support on Windows. Nice. A few comments below. >>> >> >>> >> 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/ >> > > > This is done by catching an exception number 0x406D1388 > (it has no documented name), which is thrown by the program. The name used in the MSDN article [1] is 'MS_VC_EXCEPTION', so why not use that? > + 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; > + Shouldn't this check for ExceptionInformation[0] = 0x1000, and treat this as an unknown exception otherwise? > + named_thread_id = (DWORD) current_event.u.Exception.ExceptionRecord.ExceptionInformation[2]; > + thread_name_target = (uintptr_t) current_event.u.Exception.ExceptionRecord.ExceptionInformation[1]; Is this going to be correct for 64-bit builds? > + > + 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)) Does thread_name end up not being null terminated if the thread name length really exceeds 1024? (or is improperly not null terminated in the target process...) > + { > + if (thread_name != NULL && thread_name[0] != '\0') > + { > + xfree (named_thread->name); > + named_thread->name = thread_name; > + } > + else if (thread_name != NULL) > + { > + /* nothing to do */; > + xfree (thread_name); > + } > + } > + result = 2; > + } > + break; > default: > /* Treat unhandled first chance exceptions specially. */ > if (current_event.u.Exception.dwFirstChance) > @@ -1153,7 +1194,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 +1551,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. */ > -- 2.4.0 >