From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43886 invoked by alias); 24 Aug 2017 19:02:15 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 42344 invoked by uid 89); 24 Aug 2017 19:02:14 -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=immune, H*f:sk:48d4ff8, H*i:sk:48d4ff8, sk:THREAD_ 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 ESMTP; Thu, 24 Aug 2017 19:02:13 +0000 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C8E5961483; Thu, 24 Aug 2017 19:02:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C8E5961483 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=eblake@redhat.com Received: from [10.10.123.71] (ovpn-123-71.rdu2.redhat.com [10.10.123.71]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8CE647F38C; Thu, 24 Aug 2017 19:02:09 +0000 (UTC) Subject: Re: [PATCH] headers: avoid bareword attributes To: Sebastian Huber , newlib@sourceware.org References: <20170817015011.9345-1-eblake@redhat.com> <48d4ff8a-8487-9b06-8ead-d779722dca5b@embedded-brains.de> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg Message-ID: <99c39477-3bcd-57ab-67f8-6bc84881c77e@redhat.com> Date: Thu, 24 Aug 2017 19:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <48d4ff8a-8487-9b06-8ead-d779722dca5b@embedded-brains.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j7rtoO4mfirHKRP53fsMniX347jpfmRbo" X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00869.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --j7rtoO4mfirHKRP53fsMniX347jpfmRbo Content-Type: multipart/mixed; boundary="7bwgcocwPQiclPtXpAbNXtLKdh8gdgmbS"; protected-headers="v1" From: Eric Blake To: Sebastian Huber , newlib@sourceware.org Message-ID: <99c39477-3bcd-57ab-67f8-6bc84881c77e@redhat.com> Subject: Re: [PATCH] headers: avoid bareword attributes References: <20170817015011.9345-1-eblake@redhat.com> <48d4ff8a-8487-9b06-8ead-d779722dca5b@embedded-brains.de> In-Reply-To: <48d4ff8a-8487-9b06-8ead-d779722dca5b@embedded-brains.de> --7bwgcocwPQiclPtXpAbNXtLKdh8gdgmbS Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 3288 On 08/24/2017 12:44 AM, Sebastian Huber wrote:> Hello Eric, > > On 17/08/17 03:50, Eric Blake wrote: >> Always use the __-decorated form of an attribute name in public >> headers, as the bareword form is in the user's namespace, and we >> don't want compilation to break just because the user defines the >> bareword to mean something else. >> > > did you test the clang thread safety analysis after this patch? It not > longer works using clang 3.8. I get now errors like this: > No, I usually compile with gcc, not clang. > error: use of undeclared identifier '__mutex' > __locks_exclusive(*__mutex); Can you figure out what the preprocessor is producing at the point where clang is complaining? __locks_exclusive(*__mutex) should expand to __lock_annotate(__exclusive_lock_function__(*__mutex)) where that expansion then depends on: #if __has_extension(c_thread_safety_attributes) #define __lock_annotate(x) __attribute__((x)) #else #define __lock_annotate(x) #endif Hmm, it looks like gcc lacks c_thread_safety_attributes, which means compile-testing under gcc didn't really test anything, since under that compiler, the overall expansion is empty. But if I'm right, then under clang, the expansion would be: __attribute__((__exclusive_lock_function__(*__mutex))) If that is not valid syntax under clang, then I would argue that the bug is in clang for providing a bareword attribute with no __-decorated counterpart (particularly true since clang borrowed the __attribute__ syntax from gcc, and gcc long ago made it a point that bareword forms always have a decorated counterpart, precisely for the use case of public headers that must be immune to macros in the user's namespace). A google search found https://clang.llvm.org/docs/ThreadSafetyAnalysis.html as documentation of some of the attributes supported; which recommends: // Enable thread safety attributes only with clang. // The attributes can be safely erased when compiling with other compilers. #if defined(__clang__) && (!defined(SWIG)) #define THREAD_ANNOTATION_ATTRIBUTE__(x) __attribute__((x)) #else #define THREAD_ANNOTATION_ATTRIBUTE__(x) // no-op #endif #define CAPABILITY(x) \ THREAD_ANNOTATION_ATTRIBUTE__(capability(x)) ... #ifdef USE_LOCK_STYLE_THREAD_SAFETY_ATTRIBUTES // The original version of thread safety analysis the following attribute // definitions. These use a lock-based terminology. They are still in use // by existing thread safety code, and will continue to be supported. ... // Replaced by ACQUIRE #define EXCLUSIVE_LOCK_FUNCTION(...) \ THREAD_ANNOTATION_ATTRIBUTE__(exclusive_lock_function(__VA_ARGS__)) Uggh - their example uses the bareword form, which does NOT make it obvious whether the decorated form should work. It also states that we are using the older spelling form, and should consider migrating the newlib code base to the newer ACQUIRE macro form. > > If I revert this change it works. I still think this is more likely to be a bug in clang, but I'm also okay if we need to revert this part of the patch since it only affects attributes that only clang uses, and since I don't test on clang. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org --7bwgcocwPQiclPtXpAbNXtLKdh8gdgmbS-- --j7rtoO4mfirHKRP53fsMniX347jpfmRbo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 619 -----BEGIN PGP SIGNATURE----- Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAlmfIrAACgkQp6FrSiUn Q2oIMwgAlNiqU98wpciII0Z7ZNrhg1V0SAk/ekofE7/qdm0tPDBQtKXq7WQTUeW4 24nk7kjBQaXvq9Ack4sV79Vue5Fk8y9IGo65kWFHVc/IY5ozjXpBVQW9ynWk6rNu /njnpR791YcBCzS/FZPa6MD9Jkzr2gOx3SV6UhMWTPBeiH/a7ZGL9g3QtowriC7a AhjKwYNd/oQ0y79SFv4P6MR3/KwVvxKOgkwL3wSTb2/J3YYAOGbYd13qtbgweaCg fhFhMH8byFL9gDrHuZDhEYRbGTcN9IG+rFqOf7YR1rs6tWsPk3JG2Djuno0jAWrN 2o4mQ0opMGVU408DpJo4pm2QLtpnig== =eXAT -----END PGP SIGNATURE----- --j7rtoO4mfirHKRP53fsMniX347jpfmRbo--