----- On Jul 14, 2020, at 5:58 AM, Florian Weimer fwei...@redhat.com wrote:
> * Mathieu Desnoyers: > >> + /* >> + * Very last field of the structure, to calculate size excluding padding >> + * with offsetof(). >> + */ >> + char end[]; >> } __attribute__((aligned(4 * sizeof(__u64)))); > > This makes the header incompatible with standard C++. One alternative would be to add a helper to compute the effective size on c++, e.g.: /* Always updated with struct rseq_cs declaration. */ #define rseq_last_field kernel_size static inline size_t rseq_effective_size(void) { return offsetof(struct rseq, rseq_last_field) + sizeof(((struct rseq *)NULL)->rseq_last_field); } > > How are extensions going to affect the definition of struct rseq, > including its alignment? The alignment will never decrease. If the structure becomes large enough its alignment could theoretically increase. Would that be an issue ? > As things stand now, glibc 2.32 will make the size and alignment of > struct rseq part of its ABI, so it can't really change after that. Can the size and alignment of a structure be defined as minimum alignment and size values ? For instance, those would be invariant for a given glibc version (if we always use the internal struct rseq declaration), but could be increased in future versions. > With a different approach, we can avoid making the symbol size part of > the ABI, but then we cannot use the __rseq_abi TLS symbol. As a result, > interoperability with early adopters would be lost. Do you mean with a function "getter", and then keeping that pointer around in a per-user TLS ? I would prefer to avoid that because it adds an extra pointer dereference on a fast path. > One way to avoid this problem would be for every library to register its > own rseq area, of the appropriate size. Then process-wide coordination > in userspace would not be needed. I did propose the code to do just that in my initial rseq implementations, but the idea was shutdown by kernel maintainers because it required the kernel to handle a linked-list of rseq areas per thread, which was more complex within the kernel. Thanks, Mathieu > > Thanks, > Florian -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com