From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
Peter Zijlstra <peterz@infradead.org>,
paulmck <paulmck@kernel.org>, Boqun Feng <boqun.feng@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: librseq: update to support upcoming glibc 2.35
Date: Mon, 13 Dec 2021 16:47:13 -0500 (EST) [thread overview]
Message-ID: <1553328188.30888.1639432033281.JavaMail.zimbra@efficios.com> (raw)
Hi,
I've made a few updates to librseq to support the upcoming glibc 2.35.
My goal is to provide rseq support when linked against older glibc
(without rseq support) and use glibc's rseq registration when it is
available.
In order to achieve this, librseq now exposes 3 symbols:
- rseq_offset,
- rseq_size,
- rseq_flags.
It looks up for glibc's __rseq_offset, __rseq_size, and __rseq_flags
symbols in its library constructor with dlsym(3). If those are found,
then their values are copied into the variables exposed by librseq's
public symbols. Else, if glibc symbols are not found, librseq rely on
an initial-exec model TLS to keep its rseq per-thread ABI. It relies
on the fact that a initial-exec model TLS has a constant offset from the
thread pointer.
librseq's public headers now use librseq's own rseq_offset, rseq_size, and
rseq_flags symbols.
You can find the development branch implementing this here:
https://github.com/compudj/librseq/tree/prep-glibc-2.35
After we agree on the approach, I plan to upstream this code into the
Linux kernel selftests so they become compatible with glibc-2.35.
Comments are welcome.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next reply other threads:[~2021-12-13 21:47 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 21:47 Mathieu Desnoyers [this message]
2021-12-14 9:06 ` librseq: update to support upcoming glibc 2.35 Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1553328188.30888.1639432033281.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox