Date:   Mon, 13 Dec 2021 16:47:13 -0500 (EST)
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>
Message-ID: <1553328188.30888.1639432033281.JavaMail.zimbra@efficios.com>
Subject: librseq: update to support upcoming glibc 2.35
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Thread-Index: L7in8kPdmTCMid9ZoorJ3ovpIgIMiA==
Thread-Topic: librseq: update to support upcoming glibc 2.35
Precedence: bulk

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