From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57243 invoked by alias); 25 Jul 2016 13:34:45 -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 57219 invoked by uid 89); 25 Jul 2016 13:34:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=25072016, 25.07.2016, 1025, offer X-HELO: mail-lf0-f48.google.com Received: from mail-lf0-f48.google.com (HELO mail-lf0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 25 Jul 2016 13:34:34 +0000 Received: by mail-lf0-f48.google.com with SMTP id l69so128513830lfg.1 for ; Mon, 25 Jul 2016 06:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=OOu0/jKGvTztUXuk/yzIYBUFf9TR/aM8Rw4adszcVTs=; b=Ya3dwWsjHe7oupjsGyX0wgmZKUFzCrvbI1yBXMWU56/+275qT3G4uTNK8Xn9cvCVyP dQVMzoGTJQGSViXhwk4+S/+riP49fvoIRVB7AN+JnuNwIegw+AAjut5yKA9npn+zvEsT mgpQF/SVNrhxI0BTWVhkoD8MMSvVYKNUpnelekjqpvouCr1XgtnxfAPP+LN/T9mPUi0d FwYTbmiXmfOTW2QKIHYnN3EK7PI0Z+vjKFicZ5dr4PfOvqAAKak58fRO2gZG0uh4aL0L DWBWILXsPbk/NsN8xzL2ZYBjPsP4x/n0+b8Z6PjpEpT7z5pW6Huu2aqcUcHT0RdSG1mp H0wQ== X-Gm-Message-State: AEkooutiHB8yulX/ep67ORbPJnM2A8FNJ0/7myh6guZSIlFYPtudwO9Kx2t7SnBwq2+qHg== X-Received: by 10.25.32.136 with SMTP id g130mr8183301lfg.184.1469453670046; Mon, 25 Jul 2016 06:34:30 -0700 (PDT) Received: from [192.168.4.39] (broadband-95-84-200-6.nationalcablenetworks.ru. [95.84.200.6]) by smtp.gmail.com with ESMTPSA id e73sm5486424lji.31.2016.07.25.06.34.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 06:34:29 -0700 (PDT) Subject: Re: Program-assigned thread names on Windows To: gdb-patches@sourceware.org References: <5052d495-ea40-b364-96ea-9e68c90bd747@gmail.com> <14995502.J10EtrK3xV@ralph.baldwin.cx> <6a3446f9-63dc-67a1-3702-203d77c8d85d@gmail.com> From: LRN Message-ID: <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> Date: Mon, 25 Jul 2016 13:34:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:50.0) Gecko/20100101 Thunderbird/50.0a1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OL63I8tJ6MKMDi85c3SSANGQSUj171u9R" X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00328.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OL63I8tJ6MKMDi85c3SSANGQSUj171u9R Content-Type: multipart/mixed; boundary="Bkqi6VC5FO97cEQ70stC64AL4pV0DdLM0" From: LRN To: gdb-patches@sourceware.org Message-ID: <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> 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> In-Reply-To: --Bkqi6VC5FO97cEQ70stC64AL4pV0DdLM0 Content-Type: multipart/mixed; boundary="------------83D83AEDA1B39B95106D8B64" This is a multi-part message in MIME format. --------------83D83AEDA1B39B95106D8B64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 4233 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=3De118856430a798bbc529691ad235fd0b0684439d >>>>>> [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. >=20 > The name used in the MSDN article [1] is 'MS_VC_EXCEPTION', so why not=20 > 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). >=20 >> + case WINDOWS_THREADNAME_EXCEPTION: >> + DEBUG_EXCEPTION_SIMPLE (WINDOWS_THREADNAME_EXCEPTION_S); >> + ourstatus->value.sig =3D GDB_SIGNAL_TRAP; >> + if (current_event.u.Exception.ExceptionRecord.NumberParameters = =3D=3D 4) >> + { >> + DWORD named_thread_id; >> + ptid_t named_thread_ptid; >> + struct thread_info *named_thread; >> + uintptr_t thread_name_target; >> + char *thread_name; >> + >=20 > Shouldn't this check for ExceptionInformation[0] =3D 0x1000, and treat=20 > this as an unknown exception otherwise? Yes, it should. >=20 >> + named_thread_id =3D (DWORD) current_event.u.Exception.ExceptionRecor= d.ExceptionInformation[2]; >> + thread_name_target =3D (uintptr_t) current_event.u.Exception.Excepti= onRecord.ExceptionInformation[1]; >=20 > 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_tar= get? 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). On the other hand, the example code for throwing the exception uses 32-bit DWORD fields explicitly. I don't know what the OS does between the exception being thrown and given to gdb. I'll try to use i686 gdb to debug an x86_64 process, but the reverse would be difficult, as i lack an established buildsystem for building x86_64 gdb. EXCEPTION_RECORD layout aside, casting thread ID into 32-bit DWORD should be OK, because thread IDs are 32-bit even on 64-bit Windows. Casting thread_name_target to uintptr_t is less clear. On one hand, it could be x86_64 pointer in debugee address space. On the other hand, there are some calls in windows-nat.c (to WriteProcessMemory(), for example) that do this kind of casting. Most likely the correct way to do this is to cast it to CORE_ADDR... This will most likely produce extra warnings after EXCEPTION_RECORD -> EXCEPTION_RECORD32/64 change, i'll see what gcc has to say about this. >=20 >> + >> + if (named_thread_id =3D=3D (DWORD) -1) >> + named_thread_id =3D current_event.dwThreadId; >> + >> + named_thread_ptid =3D ptid_build (current_event.dwProcessId, 0, name= d_thread_id), >> + named_thread =3D find_thread_ptid (named_thread_ptid); >> + >> + thread_name =3D NULL; >> + if (target_read_string ((CORE_ADDR) thread_name_target, &thread_name= , 1024, 0)) >=20 > Does thread_name end up not being null terminated if the thread name=20 > length really exceeds 1024? (or is improperly not null terminated in the= =20 > target process...) Good point. I think it's best to check the last byte in the string to be 0, using the value returned by target_read_string(), and set it to 0 if it isn't. Give it 1025 instead of 1024 as the maximum (although either is arbitrary, really). --=20 O< ascii ribbon - stop html email! - www.asciiribbon.org --------------83D83AEDA1B39B95106D8B64 Content-Type: application/pgp-keys; name="0x6759BA74.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x6759BA74.asc" Content-length: 3718 -----BEGIN PGP PUBLIC KEY BLOCK-----=0A= Version: GnuPG v2=0A= =0A= mQINBFd+4e0BEACxh5wQhm5pG3DMdXokYTZYyncAc0MGQkuCG7+0CUa06VW+qVz3=0A= x+wkWRSJSbFrltSzNpKY67kOGPc1b7e1V4vIQ5ubNSYNOnwqFedEorBCyA6jvpfE=0A= vmLHcWJyK6emZC2s09ToxN1ovzcJBkQMgpJNYj4jZHdHEJ0PD+qEp7bKTXlxzWXM=0A= oHjPdykSLPDuTzQ1Gi09OakKhzOUvg+3Lgqo1aAf+r8HtysM19wUE06h1BYpsMo/=0A= gP87w/uhyqrqqAPBb3tpJtAhw8OcUREsJ4GC5zsp80eHy7IS6LIrPB3nf9XyIxvd=0A= 5qql9y1XclbB/sTGfD2Z27gYLLqFDIlYxXKT1z999yGN71gXYoLi9wbqpP0VSbdh=0A= tr8LVhGiuP+BPNq1y62wKyBKpJulBq2TnYWhukYowI1tCkCFeL1F0yG2M0RTvo3P=0A= dUp6YSHiNbuvgiFzoow2YVCPW+w2MBFR2S1Si72Yegq2+tf5Dd0mSOEKOhaChz/X=0A= L3gFlbjgaF0qA879Q/8pppjdsmwDY+q48WV4NnI3bPsTlZ6dKnI0ZMpct9Kfi7E5=0A= dmexGdOCde4RbEs4dOsdMhjFl9B1YQPjKpTmh7FtoTDJqMklZEAzBr+pEDb7BorM=0A= Beh2aHsJ0Z7Qd52BCaUAIuPUXjwXDI4qzf7UyWLFS66BkeDXBRDRWaRL5QARAQAB=0A= tBdMUk4gPGxybjE5ODZAZ21haWwuY29tPokCPwQTAQgAKQUCV37h7QIbIwUJCWYB=0A= gAcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEI2t6SdnWbp0qtoQAIjcnzeN=0A= riwftAfLsnXKYBrxmdbfPsmu4G7cQxsabst841sOrvWFPHTkEZk/xpfyQgxpZEiB=0A= 8uF82XKNbHNh9+nWqiDyt/Y9v23IIt1fIodOuB1q3Jdbh7nraflgzeji91rR3BuP=0A= mKcbpX+t4zlOg2RNh3dG+xoY91C5gXXWqBZ73kyGDHkpp2jGFXNStzdlcR4qLBiV=0A= dbtXfU/mnmB3tFuojx/zgL71816G2toBZzeWT/6c7UnmrubarvbNIVPbYufM0Xzw=0A= 7sK1y+i6p+QnZPZJ7nytINAVAZJ3pxle1Ajwb5p4QAVSsau78iG04/9cNU+gtftT=0A= kwNOIJ0LDnj+S6A58uLIr2Ebl4Jr4g0MPlw74CsUIspQz9sb6/yANLQ98kz3PrUa=0A= MpodI2dNpV8UROoJ/t96ys755FcEb/09SDJcTUx7QlPukgoq4mrWqB59kVID7CKq=0A= HRRDanuoyR/+ITDUxXUEUIJkWGYzUfKzjI8ditBCI6zxNftWCaiw5XkrEEpctvzS=0A= CBbNE7KjAoFbZDnsXHgg9xZWpAzYYP6aCmBvpjISMGihXbw1oS6mJvvHTFSzjTvX=0A= QHShvyO8XLI7Q+NwrYV+mVNvtBX+mQaTsQdS9knSpoHHO/N0QlCUzbnPIEOVKjN6=0A= Hw7bcBokYeI0ez3yMZlf/bU/yyMRfxskOqxciQEcBBMBCAAGBQJXfuIzAAoJEOs4=0A= Jb6SI2CwxPgIAJtQBb/79MSdZZb3kggOC0ClZ7WDRSdP31R272gdckcbqVqm7vMl=0A= 0OZxQH5G4QRuFNLMSJG5ytf//qoxYj5CmvQS5NkP/sgnMaHvjHG+jRaBfB9t00Um=0A= h24BBL04Ac0lv3eiBc64nUJT37dEBUNEE8fgQ67gnV1hacqybVXqWIm1RXluL+Un=0A= fdFsbD6KWHLY2uPrARXdLYT7veUPnEgziw4s/2AVrGHiSgNZV1Z8pFMsuiUGpCRr=0A= 1K0r8b6hP3nxa0xxzk83NrKI6ZL1Jyhlqe7dLSWaSVofHk9WmcARZ+hJ/PlP+9N5=0A= Fd5ZuJ9R5t8C0gUB5v1ID4vPxt/YFCeiVJy5Ag0EV37h7QEQAKcbtHNm2vc6aYgR=0A= /eK0cJmJOqV3S0PtXychIV6zYj2/DppUOttsQN39nEgTBui1QFYfVgYNv3S0DBZY=0A= ESSijTLrzyCbzYL9AL/OzIgo++m8F0lERhhMKsVKtdZWLBflkQgPgCpMdwqhGdRP=0A= 5WrximbRtHN7JD4TCfupCqepefqvxyYv/pHYcDTFEycEChkRgCpc88tTxNdAyd2+=0A= F7lfvMxsgGmNcMa5IzIm1GXjKQONyiMffmjYT0Sod/AS/RA7z3aTv9/2Sm4TLgae=0A= 4BtV+ZU39VMkfA8c2DsnVi4zVKOBho7MH/Lwar2bQwKZ8U1TKhKDwK0Q1eYTq+3U=0A= Nc6Rk/9QolYpYup7/lH5wWppPvipqlltTQa6F0csD6AIc9W7rO7RVFo+lqvrEZAw=0A= AUXrRCTFtBijg715eZenDzS0QZw9WtQ6ufhsAamap6hJQmIZD3HdWdrHCT1TQ/Tt=0A= JzPAyIYbRbKCe2hoxUojF0A/P1ZL90kf/OZPQ6Oisl5XMyuyiJFgVbdbXYMJ+f+k=0A= 3pTrVxB9vASmGxX3LXCxVJAZ9xJWdBC73VK7rwit0tA8ijekrmkhSjZlIZCKvDYA=0A= j9fV4O6QXRuuFZKo4xGYWCIPFwe802jOrbvQw8YT5CgN7hGMUyHV/GCH50uUoVJD=0A= andFGy7hvTckfXk85oXARMswdyQ3ABEBAAGJAiUEGAEIAA8FAld+4e0CGwwFCQlm=0A= AYAACgkQja3pJ2dZunQeVQ/9FtseE5WqnmvPGc5NPGvbWhrd5x9CpStPG9b+xsBu=0A= 91ZXrMHsNOVQ0SxFdB708OT15sTy1ldeemxUK62E5XO1bvFJ4R1gHkWe6K/j9TfG=0A= Fshbyl3J6WKwG2qwT2JpNVpb+6QShFZVRe9a1rn3D/DNZurj3XYgVQGWlYVYT/LA=0A= 32zmBjQEzSXMbDBR/wSiJzYqgTB+9udGkcrYVgrmNz5YSA2mp6l1+PH/i++FD4j/=0A= KWFVnmqt1QqT8Q0l4MYQH65MdzHdspwfMt0XZ5abnubWIO78ImbOA/CD7MwbuWvy=0A= zezkiDcqQQ2G8mu/ER3oByfQ84iMIxGv1V608EBddHWygd6YQIKdScay0D+54IUz=0A= DXyv9tcnAAnxvMM5wzJyjWytOwL2H7FvSVAtfdywaF2wZA0iHho5Df8OeZdPEZhF=0A= 85GngH3hOBE0EAUMSFwThhRU7a2oMLSTFXRg0bKC3n0MoNExAV/oKiSM5HC06PsP=0A= exONpT/8WHL6GRk6vfsj09m7qScZSvyX35TxggnEHNwNW5/aYKIuhsXohxhLkUqM=0A= Bzu9/Xdq0xPOTyJSTberO8LR1TdWwi2WtPEBOtD25VMtEwhHrX3BKBkmYVu5f7vr=0A= CZikOLr7N8a5zJHJIiEdA2uljajBVTkPRCbMVsIBN2VVPcY2YOyNmG4gAtYmuDRL=0A= rb8=3D=0A= =3D8FDv=0A= -----END PGP PUBLIC KEY BLOCK-----=0A= --------------83D83AEDA1B39B95106D8B64-- --Bkqi6VC5FO97cEQ70stC64AL4pV0DdLM0-- --OL63I8tJ6MKMDi85c3SSANGQSUj171u9R Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 819 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXlhVhAAoJEI2t6SdnWbp0Zz4P/2dNsh0IYKee1HeH5mOkspsQ SHkMm+2tdB/8EufAGXQ2Q7AERUn7bvGS8bQmNuzgT7NDbeAV6aoknFtZ0QQKRYEb OvMz5TIkljcXxi//HhUWVEoTuv2XgFB4wWkdoN/53s3sqtxPE5wFMhAp7a492nQG fXlzhYVXunmQIVFR3OmF25olcs9WtBDhSIotZF444Rkb60slLtZ6Y7np0fXHGkDI blvteFTy5dfRruHc5OMPRhuCjQN/kI15WO8ZAAS4nIflCYgVFV79DVnbUAHTRczI HHV7kH6oB3MHj2Vm2dzOgzpRBbU8H40Lj6D5OHglGl5Q5jFQJAab0/2triRQ4fR2 YVHzXQ1rQ9IUC7gnppV08rRPhjs1IocTdGDTPZuXictY22E/6PHCDMYd0C5QSoFy T4Bo6p5fzzQ15WwWnsMz1sZsxB5G6URp6/U0EsEcG7i3Vbpgcbu6/ecl2hYYOVMg rR8EmLrPiVtmGXfq1wewMeaTBz3wa4qr9E9Fvf7mJ40h234C5hoyTp8ylhDjoruB d+dFmxlflH/iKSz8oUYB+mSRHWjZ4Yxn5sL2qw4R1piWW2QfZQQUUW2VPKAywOQ7 v1AzsyGR56aKa1UYQXJNzWLpQu+gsKF1Kzh6OzPpmvTGoNzCrBAtRHkrQzw7nRWl rgK4/ZfV8TTcfiuv6xxF =cEQR -----END PGP SIGNATURE----- --OL63I8tJ6MKMDi85c3SSANGQSUj171u9R--