From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37007 invoked by alias); 25 Jul 2016 21:33:19 -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 36938 invoked by uid 89); 25 Jul 2016 21:33:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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=reserved X-HELO: mail-lf0-f49.google.com Received: from mail-lf0-f49.google.com (HELO mail-lf0-f49.google.com) (209.85.215.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 25 Jul 2016 21:33:07 +0000 Received: by mail-lf0-f49.google.com with SMTP id b199so137565289lfe.0 for ; Mon, 25 Jul 2016 14:33:06 -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:from:to:references:message-id:date :user-agent:mime-version:in-reply-to; bh=qIi6qU5L2RdupcKdyuQkGmLuTpg56ySM4UBBb2uH/yQ=; b=cQko+eNjN6VKb1CGD1ThH5F11NfIkndL/7i77A/uMH3v6BDNlTp+Za5Ey/2s/Nw9at mhNbmLOOOOQTcMyPbJXrToJblIxme3QUu7iacvlEPPtG20+CJKZpu8TXGikiodSG9PpA DLvCKIrKkVbYJpvCG9hJqYSfKcBYvbTli/nvbd5VX7NLrjaAeMqDAayj8qHVNg23FBTC POqh7ZGmEypoaBIkU6iA6wo3d+ftNC+XFhtltkqoEH08HldhtEOy6bfa6n2nL9N1TpG9 bQf06mRbuIi2g+WlVU+bOktTb5qS3DTej+XlKi6L26klUS4UYivWAcNZTPI8dMUCVnHK BYbg== X-Gm-Message-State: AEkoousCj+tf9HZdcdVBM/mwzgVmmqmTkg4JLYrt6bWk237csoiNzVob5RIhbOTMGfq1sA== X-Received: by 10.25.207.14 with SMTP id f14mr7064845lfg.231.1469482383683; Mon, 25 Jul 2016 14:33:03 -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 o36sm5909766lfi.5.2016.07.25.14.33.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jul 2016 14:33:02 -0700 (PDT) Subject: Re: Program-assigned thread names on Windows From: LRN 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> Message-ID: <28023f06-f99c-77d1-10cf-5243f2a082a4@gmail.com> Date: Mon, 25 Jul 2016 21:33: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="h7Mcob6N7KaCdrS8ei6kM9JnaEDovkTnf" X-IsSubscribed: yes X-SW-Source: 2016-07/txt/msg00338.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h7Mcob6N7KaCdrS8ei6kM9JnaEDovkTnf Content-Type: multipart/mixed; boundary="WXFXPnxd83QBJJpQUxQn4dxl8skGQeEbm" From: LRN To: gdb-patches@sourceware.org Message-ID: <28023f06-f99c-77d1-10cf-5243f2a082a4@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> In-Reply-To: --WXFXPnxd83QBJJpQUxQn4dxl8skGQeEbm Content-Type: multipart/mixed; boundary="------------89BDCBE06B8B063212E72347" This is a multi-part message in MIME format. --------------89BDCBE06B8B063212E72347 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 3638 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: >>>>> + named_thread_id =3D (DWORD) current_event.u.Exception.ExceptionRe= cord.ExceptionInformation[2]; >>>>> + thread_name_target =3D (uintptr_t) current_event.u.Exception.Exce= ptionRecord.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=20 >> THREADNAME_INFO structure, which contains a LPCSTR pointer (which has a= =20 >> different size on x86 and x86_64) *before* the thread id. >> >> So, I think this should check that NumbersParameters * sizeof(DWORD) is= =20 >> equal to or greater than sizeof(THREADNAME_INFO), then cast=20 >> ExceptionInformation to a THREADNAME_INFO. >> >>> Tough this is a good point. MSDN says that i686 and x86_64 EXCEPTION_RE= CORD >>> 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,= =20 >> so perhaps that is all moot (although if that is the case, perhaps it=20 >> should diagnose attempts to do that) >> >=20 > Yep, just tried to attach to a 64-bit process from a 32-bit gdb, and gdb > failed to attach. >=20 > I'll try to come up with a way to build 64-bit gdb... it might take a whi= le > though. >=20 1) 64-bit gdb can attach to 32-bit debugees. 64-bit gdb sure throws a number of warnings when attaching to a 32-bit debugee, but still attaches. However, it quickly gets into a tailspin, if i do anything other than "run" (set breakpoints, step through functions). 2) EXCEPTION_RECORD does not need to be casted into EXCEPTION_RECORD32 or EXCEPTION_RECORD64 for native processes, as it's correctly aligned in either way ("2x4, 2 pointers, 4, pointer" - for 32-bit case everything is tightly packed and 4-byte aligned, for 64-bit case the last pointer moves 4 bytes further to be self-aligned to 8 bytes, while everything else remains the same), so we can keep accessing stuff via EXCEPTION_RECORD natively. That is, EXCEPTION_RECORD64 is how EXCEPTION_RECORD normally looks in 64-bit process. 3) EXCEPTION_RECORD that we receive is sized to *gdb* bitness. That is, casing it to EXCEPTION_RECORD32 in 64-bit gdb will always lead to bad interpretation, even if debugee is 32-bit. 4) ExceptionInfromation array that we receive as part of EXCEPTION_RECORD 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 aligned to 8 bytes. Therefore, it's safe to always use EXCEPTION_RECORD as-is, without worrying about alignment of the ExceptionInformation data. 5) 64-bit gdb receives an EXCEPTION_RECORD with NumberParameters =3D=3D 6 w= hen debugee is 64-bit. The contents of the extra 2 elements are a mystery (they 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 4th parameter. --=20 O< ascii ribbon - stop html email! - www.asciiribbon.org --------------89BDCBE06B8B063212E72347 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= --------------89BDCBE06B8B063212E72347-- --WXFXPnxd83QBJJpQUxQn4dxl8skGQeEbm-- --h7Mcob6N7KaCdrS8ei6kM9JnaEDovkTnf 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 iQIcBAEBCAAGBQJXloWNAAoJEI2t6SdnWbp063wP/0j/ZIGvxjsXVlFeuIcB/UYu exM4M1Ddmrkq4KHQZzxQ41gI4EyGy0KLT7JKSWQDRt3eQKEwqs8mbkPKV66iPXt0 NuE6oWlBUhYgeGCjpl1WsHvEvmlR6coMFn22YHevq+8YAYqQe+DhuacCyj30OV18 rtCpVDPkhS/PrQlDqcWTow5GnZAHn6N2pNVqQU/W6zn2OdvCR9NmJnKNt698oyxj SZmk6ZjRPFkaQ06bcyOTMBr3vK5S/6Mr6balusEGPSb4U7lNga5eLIYEzKFRXD7d qCF69+Y2WPga8iP+YDe0dXzL1OHPqZYukv4OxXOku2gqto61poS+O8sfA+kzUI5d 22LhWtPGtNlmqpXvidmxCXE5cer8yyp1DGXXZdT1lxNEvMaiY2LuJmBddh8ijsZF npuPZHVqg71xHB4fnEIwPnQOuqSlohvNiGOSk+B7wtlbs9JtNoa/MqHnFgL8EEfA ZUgy6EZe+RT+YQyBu6ZqKAgHCxVkQw3P6YvSYT9nb3R4U+3gX584ZnQDJkAe7Orv nR2nUf4YQbK+rEr2tNR5aDo1HDNC5ibFlTAlo2R8QxhikjceyKfBpLrZh1FmOZ0+ baA6tIuE5JK0FPuEX4+y43zBBFKb9FbCOsbzxrN9FiLCTM89NZmkVZO6u6EZIZ2X 4lysX+MVkFOlOabLT488 =ri7g -----END PGP SIGNATURE----- --h7Mcob6N7KaCdrS8ei6kM9JnaEDovkTnf--