Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp447886ybg; Wed, 3 Jun 2020 05:07:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCEZcxZF7UmzmXYTZDL6mHyC5p/yRpIV4fpq/fglnyGgXqygDrBWXr8YQuO3Opkhw3Zh4d X-Received: by 2002:a17:906:f1d5:: with SMTP id gx21mr13813721ejb.416.1591186059958; Wed, 03 Jun 2020 05:07:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591186059; cv=none; d=google.com; s=arc-20160816; b=ESpV0JD1A81hN6d8l0N9Mx4hDVjuMfaYP4Chd5+I8Ho/IL4QlGrw4mn/bfO7vbGCO+ oNJNPLcNfhXe43cMfD0BsiJrBeHKd47yafzrLvfj9kv1bMgo/fgLcruzTZwJ3EbksZqX caQAqFHp/7Y25CgRWoTsq+El20F+g32yJcBzHEzeE8Hg/FHlVoulLH8r+LFV7pOCw14D XfEPh0j63o+v80MaWpiwUrnWuWHyoc8lx1mf9TkcdmMqNfSC19Tj2992y9DuKfNqX8CR R7IVTrIpqNAcIcKgGjP49KPB9OJKAMooK4hJWnp2wbqm3yLz7YOnzvr1ZCCIg+MMhzcP 8o4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:message-id:in-reply-to:date:references:subject:cc:to :from:dkim-signature; bh=veNBN0nIrJ2QwM6/V0a3q4/qqOsViBBqoFiGJMYOieg=; b=j+wGks9iIRNe2XXfTrsg650EeUNGCs9LFC4fnNb5AFR1rGuPsACGhwmKzEibh735qZ y1uEDAyx/HVSWFuqLvSZy0NerWSAyD1/SlHbLAABLt56Jud2mwrM3pNnut+5gTXA1/h+ PgVnV16TJe2Mo7LOrUShbnlcOpyWoiKMAvc1nkaQJn38PNwK5CD3b/hOmOUYDNLDaUuZ Q3xlepywb4DLluLcPahXVDImi9DXo6B2SST0gtfJEc9M2B/KQqhQqy1oAsk6MUzvVpo+ pQoP+xqwb5qAx5FAW93Nb94quipo8wlbXkLujF0vcgHJh7YYOjpBei9JM+slcoLexGfP qOHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=T7IB3cqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lh2si1049198ejb.400.2020.06.03.05.07.16; Wed, 03 Jun 2020 05:07:39 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=T7IB3cqK; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726177AbgFCMFh (ORCPT + 99 others); Wed, 3 Jun 2020 08:05:37 -0400 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:25518 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725859AbgFCMFg (ORCPT ); Wed, 3 Jun 2020 08:05:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591185935; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=veNBN0nIrJ2QwM6/V0a3q4/qqOsViBBqoFiGJMYOieg=; b=T7IB3cqKd6n/NsYeq/p1KtgdLQjmAVNqDfvvTV0rTuztiovAUErMCgngJM7ll2rCnHBUVv XzfzB7I3bwH3ge/PwuMsUuegNlbnS98dMMsoCsqNal5J/+EyWGPlzCrSKgpPF8NnMGsNZL BjhguNsBzgku4dHz/9ncO69Zh+gJDII= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-510-XQuSdKH3OeaDMD3LRIVwnw-1; Wed, 03 Jun 2020 08:05:31 -0400 X-MC-Unique: XQuSdKH3OeaDMD3LRIVwnw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D5713461; Wed, 3 Jun 2020 12:05:28 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-181.ams2.redhat.com [10.36.112.181]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E79B15C220; Wed, 3 Jun 2020 12:05:22 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: Carlos O'Donell , Joseph Myers , Szabolcs Nagy , libc-alpha@sourceware.org, Thomas Gleixner , Ben Maurer , Peter Zijlstra , "Paul E. McKenney" , Boqun Feng , Will Deacon , Dave Watson , Paul Turner , Rich Felker , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org Subject: Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v20) References: <20200527185130.5604-1-mathieu.desnoyers@efficios.com> <20200527185130.5604-2-mathieu.desnoyers@efficios.com> Date: Wed, 03 Jun 2020 14:05:21 +0200 In-Reply-To: <20200527185130.5604-2-mathieu.desnoyers@efficios.com> (Mathieu Desnoyers's message of "Wed, 27 May 2020 14:51:28 -0400") Message-ID: <87d06gxsla.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Mathieu Desnoyers: > +#ifdef __cplusplus > +# if __cplusplus >=3D 201103L > +# define __rseq_static_assert(expr, diagnostic) static_assert (expr, di= agnostic) > +# define __rseq_alignof(type) alignof (type) > +# define __rseq_alignas(x) alignas (x) > +# define __rseq_tls_storage_class thread_local > +# endif > +#elif (defined __STDC_VERSION__ ? __STDC_VERSION__ : 0) >=3D 201112L > +# define __rseq_static_assert(expr, diagnostic) _Static_assert (expr, d= iagnostic) > +# define __rseq_alignof(type) _Alignof (type) > +# define __rseq_alignas(x) _Alignas (x) > +# define __rseq_tls_storage_class _Thread_local > +#endif This does not seem to work. I get this with GCC 9: In file included from /tmp/cih_test_gsrKbC.cc:8:0: ../sysdeps/unix/sysv/linux/sys/rseq.h:42:50: error: attribute ignored [-Wer= ror=3Dattributes] # define __rseq_alignas(x) alignas (x) ^ ../sysdeps/unix/sysv/linux/sys/rseq.h:122:14: note: in expansion of macro = =E2=80=98__rseq_alignas=E2=80=99 uint32_t __rseq_alignas (32) version; ^ In any case, these changes really have to go into the UAPI header first. Only the __thread handling should remain. Otherwise, we'll have a tough situation on our hands changing the UAPI header, without introducing macro definition conflicts. I'd suggest to stick to the aligned attribute for the time being, like the current UAPI headers. The resut looks okay to me. I'm still waiting for feedback from other maintainers whether the level of documentation and testing is appropriate. Thanks, Florian