Re: [PATCH 1/3] glibc: Perform rseq registration at C startup and thread creation (v21)

----- On Jun 24, 2020, at 3:11 PM, Florian Weimer fweimer@redhat.com wrote:

* Mathieu Desnoyers:

quoted

quoted

I'm still worried that __rseq_static_assert and __rseq_alignof will show
up in the UAPI with textually different definitions.  (This does not
apply to __rseq_tls_model_ie.)

What makes this worry not apply to __rseq_tls_model_ie ?

It's not needed by the kernel header because it doesn't contain a
__rseq_abi declaration.

quoted

quoted

Is my worry unfounded?

So AFAIU you worry that eventually sys/rseq.h and linux/rseq.h carry different
definitions of __rseq_static_assert and __rseq_alignof.

Indeed, I did not surround those #define with #ifndef/#endif. Maybe we should ?

Just in case the definitions end up being different (worse case scenario), we
should expect their behavior to be pretty much equivalent. So going for the
following should address your concern I think:

I think we should keep things simple on the glibc side for now and do
this changes to the kernel headers first.

Just to be sure I understand what you mean by "keep things simple", do you
recommend removing the following lines completely for now from sys/rseq.h ?

/* Ensure the compiler supports rseq_align.  */
__rseq_static_assert (__rseq_alignof (struct rseq_cs) >= 32, "alignment");
__rseq_static_assert (__rseq_alignof (struct rseq) >= 32, "alignment");

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com