From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m15113.mail.126.com (m15113.mail.126.com [220.181.15.113]) by sourceware.org (Postfix) with ESMTPS id 423F13858004; Thu, 29 Oct 2020 07:56:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 423F13858004 Received: from [192.168.1.28] (unknown [116.236.172.42]) by smtp3 (Coremail) with SMTP id DcmowADn7Oi7dZpfU2BjLA--.41720S2; Thu, 29 Oct 2020 15:56:44 +0800 (CST) Subject: Fwd: libstdc++: Attempt to resolve PR83562 References: <3d535e7a-95dc-050f-b1d6-9802436cc669@126.com> To: libstdc++@gcc.gnu.org, GCC Patches From: Liu Hao Autocrypt: addr=lh_mouse@126.com; prefer-encrypt=mutual; keydata= mQINBFvNzjsBEADgRSHQwFcRdrKpmUxYOyjJKduTZgGP90O0ZrSUzqjuM5x/0NpjgV3PRk7S OWMJAQ3u66jyG/iZnMzpIca+gdObCtaqHPG5NyOwlUjlQcRI7tTaJWGjwVTco2np6z1msAkE L4dRCwVaud5U8LoukcQcuBiCrsdx2Sp9QUR33lUEfQajks0HKFvHHqdooHiflEY89lLpcM18 r+VMXviPrBPBoYesvYWSWLEDKnAkxl+y2KjPFnCUYFh4eHlh2GndUGPZMCYqu8t8EJcfl/Zp nRkHjRDhqwNHHj2JCTO2U12H25G0C2pvlbeZNTDnTp7m0YGsnp6RO4sFYxQE0f4rxqA1K7BP gBdlqdOJO/CasCMNeGqjP1lcSIJ38/EBLR/GyM7yNwT9P1oowy3KE+w0NlSrWxLU4zs873Ev SKx33xcmyVkZyZjMWA+OFt4LM57fK/CwJc3C0yFYJsutpP0espCr2IJLGEcP/srL71SRFZ9I nZBnV3uyWPxWDvjB0tDLmXCi1I7Uprz607yCjxEiHlclk1KSrRizRL/XJNbz3TxqbiwRjp6+ u2OJZv1j8XGb6XCWdEEyQYS47pFLHthocdlTutrHjFFMYIh8jvcX2ulX3I2aWuiqyGep32Zd gLxWCk4VdKnmLVMG53ERTXKR/GfH31uwWRpD212Zq1VU6weeVwARAQABtBpMaXUgSGFvIDxs aF9tb3VzZUAxMjYuY29tPokCVAQTAQoAPhYhBJ/XgxqbURL361kXj0GzMngiMVvEBQJbzc47 AhsjBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEEGzMngiMVvEOBAP/jnQVwl7 IQKTr1xd2WRkQ+yefR+QFP1a0ujPPSKxne0e+6K97qt51E8JELGCdIoVXlzsvaFXSIqVgncH 0VnV9ciDV7jlBI/G66btRZDfGwYBSSOmgz/rTkBrpmC8+lPbqUDWdLx5J6bjUroS8XWlN3oS RZAPI+RzWjT89S+q19HGESuV+/h9OTxO51RIeA4/XVueWXFWaZ2ZQrsiBE2HZg1rZ2654i4b OnKOgFyj4FibZXmcSgDr6O6LjaXVCm2dfZZ2jkjEMzaI/FRE/yj2EKciKk5Fjy6lpWG/xyCn YhGgI6THu1Ynbz2RMm1cSISXJkC73xfkAjpRsHM0yAFU3EAlGGMo8eDV3VhFDGftPZFqd4uN YC7ku9PSxi1UF+T//QXqerSIofLegjG9Lu3brILV6f5BqhUod6++EqenydndpSvvxHjrSFz0 qzQEDpcc/sPDQbtYayAKHYzGV6SPITiAnItoB7M43WNW56uJtULuuZhRz9r6umJa1Y+gzCkt kDW1yAcWQ5VEAcI4mUBHvbmS9KKnTbw6SRQvHSXMELOVVPYjZceiA9NacESuVuwfVLm9O7vR 4ADFm4cColAsdm62vcbLLohws1MMMAw9SvL1X0v2VxCAYf40pUPtg3DHJWwdi7By4aSc4pqn 6DtDMXrMZ3oqQKKgMM/d+ohw+KGJuQINBFvNzjsBEADGwb/XwE2xzrUnmMjsIpobIOG6sjS2 WE0n/ocTe2cWqSLxwSAwNQ9LXJSgNb9qTTSxLKN/exHFMIalpypN8gpckQ13mGziayYb2LzS 2E9Rlocp91Fv3grR5lrMkCAMtKpcSj1d4hOdMcLOTiJTmDNz06FSmSQBwO3RzrwSCFVibOWn 444cdsc2nd6R96pcff2EnT8h0wrZnwqCUmqTFxVwYcZvTCM/qh8kbUB6cFfk9qOf/az62Yxo jatBBle63xv4SyhRwIokeLzQpU3MeNTLFYEBUkD91min8Du/NfhYS3ZwU6J3vMTm+53kru2N hOMqlgBAs24aJsJYeM2YIPbLVw5ZdG9AvrxTRxVu78DTlgypYMbkM7OFGqWBNamFmhFHZkSi PVHJm225B0tByBpdpxCZtWo2K4ygjE/tqBiN26U1WBjiZb2YO6qw32hnIlSt2t8nX+R+sLJW 9ypolc/Mh+FWdQD/g0JoOimT0d8D8awF1jia8W8MkRREWuUHFEkoDL4M9t+2yNGhpBsW1cXf MUNzOyP/E6I8GzgEWWovz/ut1j6uWPABCCxytrjGwZw/yqA9yqQjHC8rdzfD2r4rKz8MRpJF qWvL4Arco90so8eJpYLHyTtV7pfVHnWXPktoPTkMqUgQ8twDeywI/VT+sgOIXBP8d5HU0afE bDr+GQARAQABiQI8BBgBCgAmFiEEn9eDGptREvfrWRePQbMyeCIxW8QFAlvNzjsCGwwFCQlm AYAACgkQQbMyeCIxW8TKUhAAuQypJgJ7wIpjzji+Y/2hAhaxEnrCsUjcF6L0b2HSvuy+F2/a kuptJWa2MGUCbzQK5/Ki9S3+s7SxfzjiTk83CB/nKPuMORGly2f84H7fyKWzJCjkxmnV7PnQ iofkJLA6uoxsVR5t72kWL/s/OwcxRP5KJvMVaSUVxWrcStfcc8+FcKetDIqS3u3rHPpJO+uW MFBOJM97Cz2sSMfJ0ZpgIpKDM5Qh/Ak2Fw6dzh99V+mpBVGEL98dAibuzdKbFBZTmgSOgaJT b7i4D0hK2fxyHZE9iiCjqlO8EIGRrjWAr8I5y+d2sDPSkuJUmFXhctRem0do+fNvmUwAyNGD SqWW0mtlTOe1Ur0rcYcgq3owgABOlM6qdbPyZ6sEUbJ0RtR86+ksfhrxtLUf0oz84eqrGjFd NYTVgomeWDuW6q+a5JX4YN9LbYc9OZhjfNTJ0q5K00JvqOHPLYertlF3uscbA+KKhvtZ3x8w o2xAthMRzUGlYy+lHGJ8zUE7PKkeD2rBYfMs7mId7EQ8UNc6ZwvmL0WtZhTiXpmJNAtWBWeG D7zfJr1Z5i/s7tOMyAi6e8J9l5pt6IPa//uByXAGcdOzPADdAxlBLPkJStS/m2RFfDTbdWiZ Flo+wGMdJXNbeLQ4ykdbLbkeTBCH9TSQVmH34GlTT/O6N8xQJF7PSp+Sn0w= X-Forwarded-Message-Id: <3d535e7a-95dc-050f-b1d6-9802436cc669@126.com> Message-ID: <99113dab-c57d-cc83-3b5a-588378fe671c@126.com> Date: Thu, 29 Oct 2020 15:56:43 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3d535e7a-95dc-050f-b1d6-9802436cc669@126.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IpJdPmyZWegkvGJX8NEWmvAwuSV9C2Yng" X-CM-TRANSID: DcmowADn7Oi7dZpfU2BjLA--.41720S2 X-Coremail-Antispam: 1Uf129KBjvJXoW3AF15tryUAFyrGr47ArW7CFg_yoWxWF4rpr WYg3s7CF4kJr4vywn7ZF1kXF12kF48Way5XryrJ34FvFZ8Gr1xKFyxKr1jyayxAwsYg3WY grsYgr15W3WqyFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jalkxUUUUU= X-Originating-IP: [116.236.172.42] X-CM-SenderInfo: 5okbz0xxvhqiyswou0bp/1tbi5B3MRlpD-n9s8QAAs2 X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_NUMSUBJECT, KAM_SHORT, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 07:56:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IpJdPmyZWegkvGJX8NEWmvAwuSV9C2Yng Content-Type: multipart/mixed; boundary="98lPdR0crdIi0mjN57HCTepmn7Gl3cUKU" --98lPdR0crdIi0mjN57HCTepmn7Gl3cUKU Content-Type: multipart/mixed; boundary="------------9BBEFB013C2372F095F29F50" Content-Language: en-US This is a multi-part message in MIME format. --------------9BBEFB013C2372F095F29F50 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I forward it here for comments. Basing on the behavior of both GCC and Clang, `__cxa_thread_atexit` is us= ed to register the destructor of thread_local objects directly, suggesting the first paramet= er should have `__thiscall` convention. libstdc++ used the default `__cdecl` convention and caused crashes on 168= 6-w64-mingw32 (see PR83562). But to my surprise, libcxxabi uses `__cdecl` too [1], but I hav= en't heard any of relevant reports so far. Original patch is attached in case you can't find it in gcc-patches. [1] https://github.com/llvm/llvm-project/blob/97b351a827677ebbedc10bfbce8ef88= 44c246553/libcxxabi/src/cxa_thread_atexit.cpp#L22=0F -------- =E8=BD=AC=E5=8F=91=E7=9A=84=E6=B6=88=E6=81=AF -------- =E4=B8=BB=E9=A2=98: Re: libstdc++: Attempt to resolve PR83562 =E6=97=A5=E6=9C=9F: Tue, 27 Oct 2020 22:38:29 +0800 =E5=8F=91=E4=BB=B6=E4=BA=BA: Liu Hao =E6=94=B6=E4=BB=B6=E4=BA=BA: Jason Merrill , GCC Patche= s =E5=9C=A8 2020/10/8 22:56, Jason Merrill =E5=86=99=E9=81=93: >=20 > Hmm, why isn't the mingw implementation used for all programs?=C2=A0 Th= at would avoid the bug. >=20 There was a little further discussion about this [1]. TL;DR: The mingw-w64 function is linked statically and subject to issues = about order of destruction. Recently mingw-w64 has got its own `__cxa_thread_atexit()` so libstdc++ n= o longer exposes it. This patch for libstdc++ fixes calling conventions for destructors on i686 so they match mingw-w64 ones.= [1] https://github.com/msys2/MINGW-packages/issues/7096 [2] Below is a direct quote from #mingw-w64 on OFTC: (lh_ideapad is me and wbs is Martin Storsj=C3=B6.) ``` [14:29:32] wbs, what was the rationale for the `__thiscall` = convention for `__cxa_thread_atexit()` and `__cxa_atexit()` in our CRT? I suspect it is correct, but it is not speci= fied anywhere in Itanium ABI. [14:30:41] In case of evidence for that, the GCC prototype (= with default __cdecl) should be wrong. [14:31:10] See this: https://github.com/msys2/MINGW-package= s/issues/7096 [14:52:05] lh_ideapad: itanium ABI doesn't really talk about window= s things, but, the function that is passed to __cxa_thread_atexit is the object's destructor function, and when calling= the destructor, which is technically a member function, it's done with the thiscall calling convention [14:52:31] lh_ideapad: example: https://godbolt.org/z/qbfWT1 (only = clang as there's no gcc-mingw there, but if you try the same there you'll see the same thing) [14:52:35] Title: Compiler Explorer (at godbolt.org) [14:52:58] lh_ideapad: the destruct function shows that when callin= g __ZN7MyClassD1Ev, the destructor, it passes the object pointer in ecx, i.e. thiscall [14:53:42] lh_ideapad: and when adding the object to the cleanup li= st, the __ZN7MyClassD1Ev function is passed directly to ___cxa_thread_atexit, which then will need to call the functi= on using the thiscall convention [14:59:54] lh_ideapad: so yes, I would agree with your patch changi= ng libsupc++ to use thiscall [15:13:01] gcc is doing the same thing with a wrong calling = convention , leaving a garbage value on i686-w64-mingw32. [15:13:38] yup, so definite +1 on your libsupc++ patch for that [15:14:00] then how about `__cxa_atexit`? [15:14:26] I would say it should work the same, but gcc doesn't nor= mally use that one, right? [15:14:29] it's not used by GCC (the standard `atexit()` is = used). [15:15:26] clang has a flag -fuse-cxa-atexit, which makes it use cx= a_atexit instead of atexit [15:15:40] I was a bit dubious on it. [15:18:59] GCC has `-fuse-cxa-atexit` too . Let me check. [15:18:59] (I tested it), clang does use __cxa_atexit if the -fuse-= cxa-atexit flag is used, and then the dtor (thiscall) is passed directly to __cxa_atexit, so that's +1 datapoint to = that it should have thiscall. gcc doesn't use __cxa_atexit for i686 windows despite -fuse-cxa-atexit, so that's no poin= ts in either direction [15:19:28] both clang and gcc use a wrapper function that fixes the= calling convention, when using atexit at least [15:20:22] `-fuse-cxa-atexit` seems to have no effect on `i6= 86-w64-mingw32-g++`. [15:20:46] exactly. so in practice it doesn't matter for gcc, but I= think libsupc++ should handle it the same [15:23:11] ok I will compose a new patch for both functions = later today. [15:23:13] :) [15:23:25] \o/ [15:24:40] then for the other issue that the user was posting about= ; I remember testing and noticing that the mingw-w64-crt implementation of __cxa_thread_atexit doesn't work with emu= tls, but in all of my tests, it has been a non-issue as it has ended up using the libsupc++ code instead [15:50:50] probably static linking is broken, so one must li= nk against shared libstdc++. [15:52:20] it doesn't matter whether it is the CRT or libsup= c++ implementation that is linked statically. [15:53:13] it seems like current msys builds of libstdc++ doesn't i= nclude __cxa_thread_atexit in libstdc++ at all. I'm pretty sure I tested this back when I made the mingw version, but I'll in= vestigate and try to pinpoint what changed (did gcc at some point start noticing that mingw-w64-crt contains it and stop prov= iding their own?) or whether I just missed something when I tested it back when I wrote it... [15:59:47] I'll follow up on that other issue and mingw bugtracker = issue, but I'll do a couple hours of comple testing/studying things first to be able to give an informed comment [16:15:34] * pamaury (~pamaury@ip-41.net-89-3-53.rev.numericable.fr) has = joined [16:27:34] wbs, there is a check in `libstdc++-v3/configure.= ac` around line 275. [16:29:22] lh_ideapad: yeah, but in my tests it doesn't pick up on = it. I test by cross-bootstrapping a toolchain, so maybe this check runs before the mingw-w64-crt actually is built [16:29:50] so it doesn't detect if just bootstrapping once, but if = building a new gcc in an already complete environment, it behaves differently [16:33:21] * Pali (~pali@0001caa5.user.oftc.net) has joined [16:34:52] ah, here it is: [16:34:52] # Only do link tests if native. Else, hardcode. [16:34:52] if $GLIBCXX_IS_NATIVE; then ``` --=20 Best regards, LH_Mouse --------------9BBEFB013C2372F095F29F50 Content-Type: text/x-patch; charset=UTF-8; name="0001-libsupc-Make-the-destructor-parameter-to-__cxa_threa.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename*0="0001-libsupc-Make-the-destructor-parameter-to-__cxa_threa.pa"; filename*1="tch" =46rom ac325bdcd6e3fa522f8b59d436cd4b3ab663de5c Mon Sep 17 00:00:00 2001 From: Liu Hao Date: Thu, 8 Oct 2020 10:26:13 +0800 Subject: [PATCH] libsupc++: Make the destructor parameter to `__cxa_thread_atexit()` use the `__thiscall` calling convention for i686-w64-mingw32 The mingw-w64 implementations of `__cxa_thread_atexit()` and `__cxa_atexi= t()` have been using `__thiscall` since two years ago. Using the default calling convent= ion (which is `__cdecl`) causes crashes as explained in PR83562. Calling conventions have no effect on x86_64-w64-mingw32. Reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D83562 Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/m= ingw-w64-crt/crt/cxa_thread_atexit.c Reference: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f3e0fbb40cbc9= f8821db8bd8a0c4dae8ff671e9f/ Reference: https://github.com/msys2/MINGW-packages/issues/7071 Signed-off-by: Liu Hao --- libstdc++-v3/libsupc++/atexit_thread.cc | 14 ++++++++++---- libstdc++-v3/libsupc++/cxxabi.h | 8 ++++++++ 2 files changed, 18 insertions(+), 4 deletions(-) diff --git a/libstdc++-v3/libsupc++/atexit_thread.cc b/libstdc++-v3/libsu= pc++/atexit_thread.cc index e97644f8cd4..4f7f982ac6b 100644 --- a/libstdc++-v3/libsupc++/atexit_thread.cc +++ b/libstdc++-v3/libsupc++/atexit_thread.cc @@ -30,16 +30,21 @@ #include #endif =20 +// Simplify it a little for this file. +#ifndef _GLIBCXX_CDTOR_CALLABI +# define _GLIBCXX_CDTOR_CALLABI +#endif + #if _GLIBCXX_HAVE___CXA_THREAD_ATEXIT =20 // Libc provides __cxa_thread_atexit definition. =20 #elif _GLIBCXX_HAVE___CXA_THREAD_ATEXIT_IMPL =20 -extern "C" int __cxa_thread_atexit_impl (void (*func) (void *), +extern "C" int __cxa_thread_atexit_impl (void (_GLIBCXX_CDTOR_CALLABI *f= unc) (void *), void *arg, void *d); extern "C" int -__cxxabiv1::__cxa_thread_atexit (void (*dtor)(void *), +__cxxabiv1::__cxa_thread_atexit (void (_GLIBCXX_CDTOR_CALLABI *dtor)(voi= d *), void *obj, void *dso_handle) _GLIBCXX_NOTHROW { @@ -52,7 +57,7 @@ namespace { // One element in a singly-linked stack of cleanups. struct elt { - void (*destructor)(void *); + void (_GLIBCXX_CDTOR_CALLABI *destructor)(void *); void *object; elt *next; #ifdef _GLIBCXX_THREAD_ATEXIT_WIN32 @@ -116,7 +121,8 @@ namespace { } =20 extern "C" int -__cxxabiv1::__cxa_thread_atexit (void (*dtor)(void *), void *obj, void *= /*dso_handle*/) +__cxxabiv1::__cxa_thread_atexit (void (_GLIBCXX_CDTOR_CALLABI *dtor)(voi= d *), + void *obj, void */*dso_handle*/) _GLIBCXX_NOTHROW { // Do this initialization once. diff --git a/libstdc++-v3/libsupc++/cxxabi.h b/libstdc++-v3/libsupc++/cxx= abi.h index 000713ecdf8..3d6217a6fac 100644 --- a/libstdc++-v3/libsupc++/cxxabi.h +++ b/libstdc++-v3/libsupc++/cxxabi.h @@ -125,14 +125,22 @@ namespace __cxxabiv1 =20 // DSO destruction. int +#ifdef _GLIBCXX_CDTOR_CALLABI + __cxa_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, void*) _GL= IBCXX_NOTHROW; +#else __cxa_atexit(void (*)(void*), void*, void*) _GLIBCXX_NOTHROW; +#endif =20 void __cxa_finalize(void*); =20 // TLS destruction. int +#ifdef _GLIBCXX_CDTOR_CALLABI + __cxa_thread_atexit(void (_GLIBCXX_CDTOR_CALLABI *)(void*), void*, voi= d *) _GLIBCXX_NOTHROW; +#else __cxa_thread_atexit(void (*)(void*), void*, void *) _GLIBCXX_NOTHROW; +#endif =20 // Pure virtual functions. void --=20 2.20.1 --------------9BBEFB013C2372F095F29F50-- --98lPdR0crdIi0mjN57HCTepmn7Gl3cUKU-- --IpJdPmyZWegkvGJX8NEWmvAwuSV9C2Yng Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEn9eDGptREvfrWRePQbMyeCIxW8QFAl+adbsACgkQQbMyeCIx W8Rucg//dPSv/s4eIvCzGmkmTKytjDmDUZaCpyGabtvy3d26ugW1S+FzsmTR6F6R b/hVJ/wxBWcrlTIcxIHH4K3EDuM51K4580lwDTHAIzvNja5Je/rqRdzc5cbIBKPM XCiEhGMUYkFHb0Hep4Ur9u4GKvtTXdaxJaulh1IUcFBlFlqPFXN1mYkGhVhMtX+/ gB3z454wnjgudHJlql8Y2SLpFceGZPOsPEQLJFx3GXk9Z9JAPtPWAZMiiwEKEH2Q Jz/PwF72aLYR0ry4jAZwtsGjk5x8/dx641JdA9mSEc+EmhrZDQKxU4vThGw8keIs TV1GUjKXgOH44kOa4znecheFpEeQ/xK71ZdpFyL4pGcqyQUs7Cd7tTSt9LdOmqTG O0Na1EX/6uxfnUFQXU+E953NBrHjCgTDZokf5/TgS0WBLoiZmpdQ5KIuQU94PEmk ry8HeJvfJ1cQSap1LBMN7inDdWyctSR4RmaDwvmJ1BM+3DOx8YXti2EYrN1p5Xm5 CsBI0G7ZS9zJW9DWKxvtbc01kqVh44oF7p8G6UUnlmPQTa3XyybxGNMo2XeCt83g UzpImOVjSe+O6ds1+ZiSI42JdDSSTtCjYHel7GdRUeS+8ZPbLB0iaToiStkDemmj Wpv2iirsegVx5GvZDF+q5s64D+3UarExsHVSBoMbmpxSTNwF/8Q= =cNGF -----END PGP SIGNATURE----- --IpJdPmyZWegkvGJX8NEWmvAwuSV9C2Yng--