From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-99233-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 25391 invoked by alias); 14 Jan 2019 19:37:14 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 25382 invoked by uid 89); 14 Jan 2019 19:37:14 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=
X-HELO: mx1.redhat.com
From: Florian Weimer <fweimer@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: carlos <carlos@redhat.com>,  Joseph Myers <joseph@codesourcery.com>,  Szabolcs Nagy <szabolcs.nagy@arm.com>,  libc-alpha <libc-alpha@sourceware.org>,  Thomas Gleixner <tglx@linutronix.de>,  Ben Maurer <bmaurer@fb.com>,  Peter Zijlstra <peterz@infradead.org>,  "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,  Boqun Feng <boqun.feng@gmail.com>,  Will Deacon <will.deacon@arm.com>,  Dave Watson <davejwatson@fb.com>,  Paul Turner <pjt@google.com>,  Rich Felker <dalias@libc.org>,  linux-kernel <linux-kernel@vger.kernel.org>,  linux-api <linux-api@vger.kernel.org>
Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at nptl init and thread creation (v4)
References: <20181204192141.4684-1-mathieu.desnoyers@efficios.com>
	<87h8fkz6qx.fsf@oldenburg2.str.redhat.com>
	<1681283664.1380.1547152315426.JavaMail.zimbra@efficios.com>
	<87fttv9iic.fsf@oldenburg2.str.redhat.com>
	<394676913.486.1547493757710.JavaMail.zimbra@efficios.com>
Date: Mon, 14 Jan 2019 19:37:00 -0000
In-Reply-To: <394676913.486.1547493757710.JavaMail.zimbra@efficios.com>
	(Mathieu Desnoyers's message of "Mon, 14 Jan 2019 14:22:37 -0500
	(EST)")
Message-ID: <87y37n8202.fsf@oldenburg2.str.redhat.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SW-Source: 2019-01/txt/msg00303.txt.bz2

* Mathieu Desnoyers:

> ----- On Jan 14, 2019, at 10:55 AM, Florian Weimer fweimer@redhat.com wro=
te:
>
>> * Mathieu Desnoyers:
>>=20
>>> Therefore, both symbols will end up in
>>> sysdeps/unix/sysv/linux/Versions.
>>=20
>> I'm not sure what you mean by that.  The physical location in the
>> directory tree has little effect on which shared object the symbol is
>> placed in; that will need other changes.
>
> I'm currently moving the symbol definitions to csu/rseq-sym.c. On Linux,
> its content is overridden by a new sysdeps/unix/sysv/linux/rseq-sym.c
> which contains both __rseq_abi and __rseq_refcount symbols. On other
> platforms, it is a stub file.

You don't need a stub file if you use the =E2=80=9Cifeq ($(subdir),csu)=E2=
=80=9D
construct.

The other question is whether this belongs into the csu subdirectory.
Since TLS is not available in ld.so, the initialization would have to
happen rather late, after relocation, but before ELF constructors are
run.

(A side effect is that the rseq area would not be usable from IFUNC
resolvers.)

Thanks,
Florian