Re: [PATCH glibc 2.31 1/5] glibc: Perform rseq(2) registration at C startup and thread creation (v12)

On Wed, Sep 11, 2019 at 09:54:23PM +0200, Florian Weimer wrote:

* Carlos O'Donell:

quoted

On 9/11/19 3:08 PM, Florian Weimer wrote:

quoted

* Carlos O'Donell:

quoted

It would be easier to merge the patch set if it were just an unconditional
registration like we do for set_robust_list().

Note that this depends on the in-tree system call numbers list, which I
still need to finish according to Joseph's specifications.

Which work is this? Do you have a URL reference to WIP?

  <https://sourceware.org/ml/libc-alpha/2019-05/msg00630.html>
  <https://sourceware.org/ml/libc-alpha/2019-06/msg00015.html>

I think realistically this is needed for the Y2038 work as well if we
want to support building glibc with older kernel headers.  “glibc 2..31
will have Y2038 support and rseq support, but only if it runs on a
current and it happens to have been built against sufficiently recent
kernel headers” is a bit difficult to explain.  The current kernel part
is easy enough to understand, but the impact of the kernel headers on
the feature set has always been tough to explain.  Especially if you
factor in vendor kernels with system call backports.

I'm in favor of in-tree syscall numbers list. If you don't want O(n)
per-arch work, though, you could just define the 'base number' for
each arch and use the fact that all the new syscalls share a common
numbering (i.e. base + constant depending only on syscall). I think
including the list with glibc is more robust though, and would
eliminate the need to check for definitions of older (pre-unification)
syscalls glibc wants to use.

Rich