From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116090 invoked by alias); 26 Jul 2016 14:17:28 -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 116078 invoked by uid 89); 26 Jul 2016 14:17:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 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=bothered, it'll, itll X-HELO: mail-lf0-f44.google.com Received: from mail-lf0-f44.google.com (HELO mail-lf0-f44.google.com) (209.85.215.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 26 Jul 2016 14:17:17 +0000 Received: by mail-lf0-f44.google.com with SMTP id g62so6132394lfe.3 for ; Tue, 26 Jul 2016 07:17:16 -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=tmZtcRbpFox1koRTRKv5zFw0JEIo4Z6iY8anEnOlglY=; b=Gcxx0qX1EAUy3FrptIaVuEPhQkwn3Wv9g2NIHJt5yH5MVqSQq0hm0PL2l8lpo9bnax o9oEE62iIuxEWmyDph4g+Uy92+tGoIpvAzRr8/OUqo1YmszMtvV23q2GK7bQeUv7ISlB aA1LAJ3iQeFUpacwy+dK1Zkw8NdGbLZHGbeX9DKPfdXHVejIt4W65Wk3EwTv9RgxWiX3 WDr7Xq1W/xsFW4n0Ir/MiuY8Kb2E46Y+kLBq3UXGtnXOjbht+O7b8sJF2Yd+GHwaXalq vAILstRRLBtmbTyak7s6Lp5j0IXcLx6BJvdtQtiLl7qP45V44lSa2RG5/rQpEiZmMijU Dhtw== X-Gm-Message-State: AEkoouuaTF7gRVmSMmqukTfqTUwFUg7H0HWAe0MG9ujeJNooTyuKZbB9Lvgh6ikhe4W7jA== X-Received: by 10.25.214.166 with SMTP id p38mr9631696lfi.168.1469542633654; Tue, 26 Jul 2016 07:17:13 -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 d142sm168907lfb.22.2016.07.26.07.17.12 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Jul 2016 07:17:12 -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> <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> <28023f06-f99c-77d1-10cf-5243f2a082a4@gmail.com> <0e59216f-77cb-608a-aa39-578c2610eda1@dronecode.org.uk> From: LRN Message-ID: <0f064b2b-6b51-f132-caa6-a4c1a85585a3@gmail.com> Date: Tue, 26 Jul 2016 14:17: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: <0e59216f-77cb-608a-aa39-578c2610eda1@dronecode.org.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VWJrxhDx1Qxgaxm26JLxmGlFT1dTKxrTq" X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00346.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VWJrxhDx1Qxgaxm26JLxmGlFT1dTKxrTq Content-Type: multipart/mixed; boundary="SsPbEoEw2OsS1lN5R3S60qsCQJeDgIHMq" From: LRN To: gdb-patches@sourceware.org Message-ID: <0f064b2b-6b51-f132-caa6-a4c1a85585a3@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> <0cabec98-8411-2c3a-98d0-3d950de02bc5@gmail.com> <28023f06-f99c-77d1-10cf-5243f2a082a4@gmail.com> <0e59216f-77cb-608a-aa39-578c2610eda1@dronecode.org.uk> In-Reply-To: <0e59216f-77cb-608a-aa39-578c2610eda1@dronecode.org.uk> --SsPbEoEw2OsS1lN5R3S60qsCQJeDgIHMq Content-Type: multipart/mixed; boundary="------------B85D83527C89B98AA2E22BC9" This is a multi-part message in MIME format. --------------B85D83527C89B98AA2E22BC9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 5381 On 26.07.2016 16:18, Jon Turney wrote: > On 26/07/2016 07:07, LRN wrote: >> On 26.07.2016 0:32, LRN wrote: >>>> On 25.07.2016 17:23, LRN wrote: >>>>>> On 25.07.2016 17:06, Jon Turney wrote: >>>>>>>> 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: >=20 >>>> 4) ExceptionInfromation array that we receive as part of EXCEPTION_REC= ORD >>>> is *also natively aligned for gdb*. I've made 32-bit debugee print out= the >>>> addresses of fields of the THEADNAME_INFO structure, and it's aligned = to 4 >>>> bytes (as expected), but examining the EXCEPTION_RECORD structure that >>>> 64-bit gdb receives shows that the ExceptionInformation array is align= ed to >>>> 8 bytes. Therefore, it's safe to always use EXCEPTION_RECORD as-is, wi= thout >>>> worrying about alignment of the ExceptionInformation data. >=20 > Ah yes, I see. >=20 > I was thrown off by your references [2], [3], which compute=20 > nNumberOfArguments for RaiseException() as sizeof (info) / sizeof=20 > (DWORD), which I think is incorrect on 64-bit, and should be=20 > sizeof(info) / sizeof(ULONG_PTR), as the MSDN example code has. Ah, that must be where '6' came from. Indeed, sizeof (THEADNAME_INFO) is [4 +4padding] + [8] + [4 + 4] =3D 24. 24 / 4 =3D 6. Also, i stand corrected. I've claimed that the array is realigned when it passes the 32-bit/64-bit barrier, and it is. However, there's no such thing when 64-bit process throws an exception and 64-bit debugger caches it. So, because, as i've shown above, not all fields are 8-byte aligned (first two fields are aligned, because one of them is a self-aligned pointer, but the last two fields are packed together into one 8-byte slot), it can look weird when ExceptionInformation[] is interpreted as an array of pointer-sized values. This is concerning, as i want the code that throws the exception to be compatible with MSVS and WinDbg, and for gdb to support *that* version. >=20 >>>> 5) 64-bit gdb receives an EXCEPTION_RECORD with NumberParameters =3D= =3D 6 when >>>> debugee is 64-bit. The contents of the extra 2 elements are a mystery = (they >=20 > I think this is a bug in the code you are testing with, as mentioned=20 > above, which doubles nNumberOfArguments ... Yep. >=20 >>>> seem to point to the stack, but that's all i can tell). Also, the 4-th >>>> element (which is "Reserved for future use, must be zero") is not zero= when >>>> the exception is caught. >>>> In light of this, we should probably check for NumberParameters >=3D 4= . Or >>>> even NumberParameters >=3D 3, given that we don't really look at the 4= th >>>> parameter. >=20 > It seems on x86_64, the structure is laid out by gcc as: >=20 > 4 DWORD dwType > 4 padding > 8 LPCSTR szName > 4 DWORD dwThreadID > 4 DWORD dwFlags >=20 > total size 24, so nNumberOfArguments =3D 3, so this is passed to the=20 > debugger as an array of 3 DWORD64s >=20 > Of course, the 'correct' layout is defined by how the sample code is=20 > laid out by MSVC, which I'm guessing is the same, but haven't checked... >=20 > So dwThreadID and dwFlags get packed together into=20 > ExceptionInformation[2]. Fortunately, dwFlags should be set to 0. >=20 > Furthermore, accessing dwType as a DWORD64 value via=20 > ExceptionInformation[0] relies on the padding being zero initialized in=20 > the debugee to have useful values! I guess you'll have to mask with 0xfff= f? I'll play a bit with the 64-bit exception-throwing example and see how WinDbg reacts to various combinations of alignment and argument counting, and will make gdb support the layout that WinDbg supports. >> + { >> + long named_thread_id; >=20 > Since this holds a Win32 thread id, should it be DWORD type? I've changed it into long, because long is what ptid_build() takes. If there's some kind of typecast going on, it'll happen when we assign things to named_thread_id, not when we pass them to ptid_build(). >> + DEBUG_EXCEPTION_SIMPLE (MS_VC_EXCEPTION_S); >> + >=20 > DEBUG_EXCEPTION_SIMPLE ("MS_VC_EXCEPTION"); ? I would actually prefer: DEBUG_EXCEPTION_SIMPLE (STRINGIFY(MS_VC_EXCEPTION)) , but i don't know if gdb has a stringifying macro somewhere, and haven't bothered to look. As i've said previously, MS_VC_EXCEPTION is not a fully-documented name. It certainly is not in any SDK. But if you *want* to show "MS_VC_EXCEPTION", that's easily done, obviously. >> + thread_name =3D NULL; >> + thread_name_len =3D target_read_string (thread_name_target, &thread_= name, 1025, 0); >> + if (thread_name_len > 0 && thread_name !=3D NULL) >> + { >> + if (thread_name[thread_name_len - 1] !=3D '\0') >> + thread_name[thread_name_len - 1] =3D '\0'; >=20 > I'd just null-terminate unconditionally. Okay. >> @@ -1510,10 +1557,19 @@ get_windows_debug_event (struct target_ops *ops, >> "EXCEPTION_DEBUG_EVENT")); >> if (saw_create !=3D 1) >> break; >> - if (handle_exception (ourstatus)) >> - thread_id =3D current_event.dwThreadId; >> - else >> - continue_status =3D DBG_EXCEPTION_NOT_HANDLED; >> + switch (handle_exception (ourstatus)) >=20 > Would it be clearer to use an enum to name these return cases from=20 > handle_exception()? It would be. Where should id put its definition and how do i name it and its values? --=20 O< ascii ribbon - stop html email! - www.asciiribbon.org --------------B85D83527C89B98AA2E22BC9 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= --------------B85D83527C89B98AA2E22BC9-- --SsPbEoEw2OsS1lN5R3S60qsCQJeDgIHMq-- --VWJrxhDx1Qxgaxm26JLxmGlFT1dTKxrTq 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 iQIcBAEBCAAGBQJXl3DnAAoJEI2t6SdnWbp0NVkP/jBR2RySfjeHAq+o4r8J3VoL WZp0GdX3yXodCGbY6g7bK9KYvdjlAVW4BqEWYWSVuytyJFWe5k/wy83tTNIvGO6B wRIyY26BxBgzz3dpHQRK4ff8ifx368h11Xuh+fp3dAM7EQUmQtorLDbK5+pW1Sj+ eUQo/n5LIv7kvuaSnyt/elr+JcKYrwzd5cRHb4POKOGFfc6JfEb2P4c7Fifdc4ed AmaD/Lvnngd53dVxvcorFjWHmGMcVFNUykdBdt2+d/CDrxS16cBhZo5/SgCF7C3K QH0vAV3K+S/wPqLSPx8u9EjES1kiGv7JMAk1bH8SGjToarsSZvUA+sX9+OXSrsJq VmcXH4BQARw43sItJV6SO+TKGEy6zZuJmi1pn3eumMDOHmbMk7Eeaq//H4E0BII/ LHzUGOywTR2miATXL2zaCKhZZXRD6Yq601H9Trud98xT4KlubsSzeumxCZjQ0ySz e+NtQRFjbf8oTuYxARiAKoOTRiL5IM7pnhOWG8zOkNC0d8Gd00Hx0mgh/HQHaXI3 jrJWsnTfDV886DovYZ7nkMRmvb+23VyLG8x4JnNYfBwphqtrtR1nFTe61BktxCvm UaVI05CabTF2Duykh21aMJ5HKDG5KlVrR+5uNBmmngc6wfh9368vS3r9QLGpaRNa MpNcWp+UASau3VUdZ3dA =WUpR -----END PGP SIGNATURE----- --VWJrxhDx1Qxgaxm26JLxmGlFT1dTKxrTq--