This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v5)
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, libc-alpha <libc-alpha at sourceware dot org>, Thomas Gleixner <tglx at linutronix dot de>, Ben Maurer <bmaurer at fb dot com>, Peter Zijlstra <peterz at infradead dot org>, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, Boqun Feng <boqun dot feng at gmail dot com>, Will Deacon <will dot deacon at arm dot com>, Dave Watson <davejwatson at fb dot com>, Paul Turner <pjt at google dot com>, Rich Felker <dalias at libc dot org>, linux-kernel <linux-kernel at vger dot kernel dot org>, linux-api <linux-api at vger dot kernel dot org>
- Date: Fri, 18 Jan 2019 12:41:45 -0500 (EST)
- Subject: Re: [RFC PATCH glibc 1/4] glibc: Perform rseq(2) registration at C startup and thread creation (v5)
- Dkim-filter: OpenDKIM Filter v2.10.3 mail.efficios.com 4416FA6DE0
- References: <20190115015148.32155-1-mathieu.desnoyers@efficios.com>
----- On Jan 14, 2019, at 8:51 PM, Mathieu Desnoyers mathieu.desnoyers@efficios.com wrote:
[...]
> diff --git a/sysdeps/unix/sysv/linux/rseq-sym.c
> b/sysdeps/unix/sysv/linux/rseq-sym.c
> new file mode 100644
> index 0000000000..6856d0388a
[...]
> +/* volatile because fields can be read/updated by the kernel. */
> +__thread volatile struct rseq __rseq_abi = {
> + .cpu_id = RSEQ_CPU_ID_UNINITIALIZED,
> +};
> +
> +/* volatile because refcount can be read/updated by signal handlers. */
> +__thread volatile uint32_t __rseq_refcount;
Back to the weak vs non-weak question about those two symbols. I understand
that tagging them as weak symbols has little effect on the dynamic loader
when it loads libc.so. However, I'm worried about that happens when
libc is statically linked into an application, and there happens to
be more than one instance of those symbols (e.g. libc and another library
define the same symbols, and both are statically linked into the same
application). Isn't it a situation where tagging those symbols as "weak"
becomes useful ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com