----- On Jul 14, 2020, at 5:58 AM, Florian Weimer fweimer@xxxxxxxxxx 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
