From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125212 invoked by alias); 17 Jan 2016 20:21:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 125167 invoked by uid 89); 17 Jan 2016 20:21:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=declaring, 2026, 195,7, 202,6 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 17 Jan 2016 20:21:51 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E3FB990252; Sun, 17 Jan 2016 20:21:49 +0000 (UTC) Received: from [10.36.5.235] (vpn1-5-235.ams2.redhat.com [10.36.5.235]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0HKLknd018515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Sun, 17 Jan 2016 15:21:47 -0500 Message-ID: <1453062105.26597.419.camel@localhost.localdomain> Subject: Re: [PATCH v2] libstdc++: Make certain exceptions transaction_safe. From: Torvald Riegel To: David Edelsohn Cc: Jakub Jelinek , Jonathan Wakely , GCC Patches , "libstdc++@gcc.gnu.org" , Jason Merrill Date: Sun, 17 Jan 2016 20:21:00 -0000 In-Reply-To: References: <20160116124323.GM15084@redhat.com> <20160116133521.GN3017@tucnak.redhat.com> Content-Type: multipart/mixed; boundary="=-5nAvMGi/a+W7lTOPH1dQ" Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg01226.txt.bz2 --=-5nAvMGi/a+W7lTOPH1dQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-length: 2378 On Sat, 2016-01-16 at 15:38 -0500, David Edelsohn wrote: > On Sat, Jan 16, 2016 at 8:35 AM, Jakub Jelinek wrote: > > On Sat, Jan 16, 2016 at 07:47:33AM -0500, David Edelsohn wrote: > >> stage1 libstdc++ builds just fine. the problem is stage2 configure > >> fails due to missing ITM_xxx symbols when configure tries to compile > >> and run conftest programs. > > > > On x86_64-linux, the _ITM_xxx symbols are undef weak ones and thus it is > > fine to load libstdc++ without libitm and libstdc++ doesn't depend on > > libitm. > > > > So, is AIX defining __GXX_WEAK__ or not? Perhaps some other macro or > > configure check needs to be used to determine if undefined weak symbols > > work the way libstdc++ needs them to. > > __GXX_WEAK__ appears to be defined by gcc/c-family/c-cppbuiltin.c > based on SUPPORTS_ONE_ONLY. gcc/defaults.h defines SUPPORTS_ONE_ONLY > if the target supports MAKE_DECL_ONE_ONLY and link-once semantics. > AIX weak correctly supports link-once semantics. AIX also supports > the definition of __GXX_WEAK__ in gcc/doc/cpp.texi, namely collapsing > symbols with vague linkage in multiple translation units. > > libstdc++/src/c++11/cow-stdexcept.cc appears to be using __GXX_WEAK__ > and __attribute__ ((weak)) for references to symbols that may not be > defined at link time or run time. AIX does not allow undefined symbol > errors by default. And the libstdc++ inference about the semantics of > __GXX_WEAK__ are different than the documentation. > > AIX supports MAKE_DECL_ONE_ONLY and the documented meaning of > __GXX_WEAK__. AIX does not support extension of the meaning to > additional SVR4 semantics not specified in the documentation. I see, so we might be assuming that __GXX_WEAK__ means more than it actually does (I'm saying "might" because personally, I don't know; your information supports this is the case, but the initial info I got was that __GXX_WEAK__ would mean we could have weak decls without definitions). The attached patch works around this by always definining stubs for the libitm functions, yet declaring them weak at the same time. If __GXX_WEAK__ is not supplied, the transactional clones aren't built at all. This tests fine on x86_64-linux, and I suppose that it should work on AIX too (but I haven't tested). Is it harmless if gnu.pre lists symbols that we don't provide? Thoughts? --=-5nAvMGi/a+W7lTOPH1dQ Content-Disposition: attachment; filename="libstdc++-weak-fix.patch" Content-Type: text/x-patch; name="libstdc++-weak-fix.patch"; charset="UTF-8" Content-Transfer-Encoding: 7bit Content-length: 2387 commit 9008d4a610dccb5ec47f9c1e506492b8615a36fd Author: Torvald Riegel Date: Sun Jan 17 19:21:13 2016 +0100 libstdc++: Fix usage of weak symbols in TM TS support. diff --git a/libstdc++-v3/src/c++11/cow-stdexcept.cc b/libstdc++-v3/src/c++11/cow-stdexcept.cc index e2d7e76..8ccc7f5 100644 --- a/libstdc++-v3/src/c++11/cow-stdexcept.cc +++ b/libstdc++-v3/src/c++11/cow-stdexcept.cc @@ -179,6 +179,13 @@ _GLIBCXX_END_NAMESPACE_VERSION // Furthermore, _Rep will always have been allocated or deallocated via // global new or delete, so nontransactional writes we do to _Rep cannot // interfere with transactional accesses. + +// We require support for weak symbols because we need to call libitm but must +// not depend on it. The exception classes will not be declared +// transaction-safe if there is no such support, so do not create +// transactional clones in that case at all. +#ifdef __GXX_WEAK__ + extern "C" { #ifndef _GLIBCXX_MANGLE_SIZE_T @@ -195,7 +202,6 @@ extern "C" { # define ITM_REGPARM #endif -#if __GXX_WEAK__ // Declare all libitm symbols we rely on, but make them weak so that we do // not depend on libitm. extern void* _ZGTtnaX (size_t sz) __attribute__((weak)); @@ -213,9 +219,10 @@ extern void _ITM_memcpyRnWt(void *, const void *, size_t) extern void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) ITM_REGPARM __attribute__((weak)); -#else -// If there is no support for weak symbols, create dummies. The exceptions -// will not be declared transaction_safe in this case. +// Also create stubs because some targets (e.g., AIX) do not support weak +// symbols that do not have a definition. These stubs will not be used +// (unless users call the transactional clones directly or run transactions +// without using libitm as well) void* _ZGTtnaX (size_t) { return NULL; } void _ZGTtdlPv (void*) { } uint8_t _ITM_RU1(const uint8_t *) { return 0; } @@ -224,7 +231,6 @@ uint64_t _ITM_RU8(const uint64_t *) { return 0; } void _ITM_memcpyRtWn(void *, const void *, size_t) { } void _ITM_memcpyRnWt(void *, const void *, size_t) { } void _ITM_addUserCommitAction(void (*)(void *), uint64_t, void *) { }; -#endif } @@ -440,3 +446,5 @@ CTORDTOR(14overflow_error, std::overflow_error, runtime_error) CTORDTOR(15underflow_error, std::underflow_error, runtime_error) } + +#endif // __GXX_WEAK__ --=-5nAvMGi/a+W7lTOPH1dQ--