----- On May 26, 2020, at 10:38 AM, Florian Weimer fweimer@xxxxxxxxxx wrote:
> * Mathieu Desnoyers:
>
>> 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.
>
>>>>> 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) {
>
>> 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.
>
>> /* 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
>> #endif
>
> If 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
