Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v19)
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: 2020-05-26 14:53:27
Also in:
lkml
----- On May 26, 2020, at 10:38 AM, Florian Weimer fweimer@redhat.com wrote:
* Mathieu Desnoyers:quoted
AFAIU, the only gain here would be to make sure we don't emit useless ";" in the "/* nothing */" case. But does it matter ?I don't think C allows empty constructs like this at the top level.quoted
quoted
quoted
quoted
And something similar for _Alignas/attribute aligned,I don't see where _Alignas is needed here ? For attribute aligned, what would be the oldest supported C and C++ standards ?There are no standardized attributes for C, there is only _Alignas. C++11 has an alignas specifier; it's not an attribute either. I think these are syntactically similar.There appears to be an interesting difference between attribute aligned and alignas. It seems like alignas cannot be used on a structure declaration, only on fields, e.g.: struct blah { int a; } _Alignas (16); o.c:3:1: warning: useless ‘_Alignas’ in empty declaration } _Alignas (16); But struct blah { int _Alignas (16) a; };Like the attribute, it needs to come right after the struct keyword, I think. (Trailing attributes can be ambiguous, but not in this case.)
Nope. _Alignas really _is_ special :-(
struct _Alignas (16) blah {
int a;
};
p.c:1:8: error: expected ‘{’ before ‘_Alignas’
struct _Alignas (16) blah {
Also:
struct blah _Alignas (16) {
int a;
};
p.c:1:27: error: expected identifier or ‘(’ before ‘{’ token
struct blah _Alignas (16) {
quoted
is OK. So if I change e.g. struct rseq_cs to align the first field: struct rseq_cs { /* Version of this structure. */ uint32_t rseq_align (32) version; /* enum rseq_cs_flags. */ uint32_t flags; uint64_t start_ip; /* Offset from start_ip. */ uint64_t post_commit_offset; uint64_t abort_ip; }; It should work.Indeed.
OK, so let's go for that approach.
quoted
/* Rely on GNU extensions for older standards and tls model. */ #ifdef __GNUC__ # ifndef rseq_alignof # define rseq_alignof(x) __alignof__ (x) # endif # ifndef rseq_alignas # define rseq_alignas(x) __attribute__ ((aligned (x))) # endif # define rseq_tls_model_ie __attribute__ ((__tls_model__ ("initial-exec"))) #else /* Specifying the TLS model on the declaration is optional. */ # define rseq_tls_model_ie /* Nothing. */ #endif /* Fall back to __thread for TLS storage class. */ #ifndef rseq_tls_storage_class # define rseq_tls_storage_class __thread #endifIf they are only used in the glibc headers, they should have __rseq prefixes, so that application code doesn't start using them (in case we have to change/fix them, or move the into <sys/cdefs.h> later).
OK will do.
Rest looks fine.
One last thing I'm planning to add in sys/rseq.h to cover acessing the
rseq_cs pointers with both the UAPI headers and the glibc struct rseq
declarations:
/* The rseq_cs_ptr macro can be used to access the pointer to the current
rseq critical section descriptor. */
#ifdef __LP64__
# define rseq_cs_ptr(rseq) \
((const struct rseq_cs *) (rseq)->rseq_cs.ptr)
#else /* __LP64__ */
# define rseq_cs_ptr(rseq) \
((const struct rseq_cs *) (rseq)->rseq_cs.ptr.ptr32)
#endif /* __LP64__ */
Does it make sense ?
Thanks,
Mathieu
Thanks, Florian
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com