From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130220 invoked by alias); 25 Jul 2016 14:07:23 -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 129914 invoked by uid 89); 25 Jul 2016 14:07:22 -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=Tough, Hx-languages-length:3176, offer 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 14:07:12 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A84162023B; Mon, 25 Jul 2016 10:07:10 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Mon, 25 Jul 2016 10:07:10 -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 0A583F29E1; Mon, 25 Jul 2016 10:07:08 -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> <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> Cc: LRN From: Jon Turney To: gdb-patches@sourceware.org Message-ID: Date: Mon, 25 Jul 2016 14:07: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: <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-07/txt/msg00333.txt.bz2 On 25/07/2016 14:34, LRN wrote: > On 25.07.2016 15:17, Jon Turney wrote: >> 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: >>>>>>> >>>>>>> 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? > > No reason. If you want, run sed -e > 's/WINDOWS_THREADNAME_EXCEPTION/MS_VC_EXCEPTION' over the patch file prior > to committing it. > > That said, i think "MS_VC_EXCEPTION" does not offer a good enough > description (doesn't mention threads, does mention VisualC). There might be current or future uses of this exception with type other than 0x1000 which aren't related to threads at all. >>> + 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? > > Yes, it should. > >> >>> + 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? > > I've only tested this on i686. > > Which variable are you concerned about - named_thread_id or thread_name_target? Both. The ExceptionInformation isn't actually array of DWORDs, it's a THREADNAME_INFO structure, which contains a LPCSTR pointer (which has a different size on x86 and x86_64) *before* the thread id. So, I think this should check that NumbersParameters * sizeof(DWORD) is equal to or greater than sizeof(THREADNAME_INFO), then cast ExceptionInformation to a THREADNAME_INFO. > Tough this is a good point. MSDN says that i686 and x86_64 EXCEPTION_RECORD > structures have different layout (well, to-be-pointer struct fields are > DWORD64 on x86_64). I don't think gdb currently supports 32/64 bit interworking on Windows, so perhaps that is all moot (although if that is the case, perhaps it should diagnose attempts to do that)