From: Florian Weimer <fweimer@redhat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: libc-alpha <libc-alpha@sourceware.org>,
Rich Felker <dalias@libc.org>,
linux-api <linux-api@vger.kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Will Deacon <will.deacon@arm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ben Maurer <bmaurer@fb.com>, Dave Watson <davejwatson@fb.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul <paulmck@linux.vnet.ibm.com>, Paul Turner <pjt@google.com>,
Joseph Myers <joseph@codesourcery.com>
Subject: Re: [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v19)
Date: Tue, 26 May 2020 16:38:45 +0200 [thread overview]
Message-ID: <87ftbmpxqi.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <1701081361.34159.1590503556923.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Tue, 26 May 2020 10:32:36 -0400 (EDT)")
* 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.)
> 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.
> /* 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).
Rest looks fine.
Thanks,
Florian
next prev parent reply other threads:[~2020-05-26 14:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200501021439.2456-1-mathieu.desnoyers@efficios.com>
2020-05-01 2:14 ` [PATCH glibc 1/3] glibc: Perform rseq registration at C startup and thread creation (v19) Mathieu Desnoyers
2020-05-20 11:40 ` Florian Weimer
2020-05-25 14:51 ` Mathieu Desnoyers
2020-05-25 15:20 ` Florian Weimer
2020-05-25 17:36 ` Mathieu Desnoyers
2020-05-26 12:41 ` Florian Weimer
2020-05-26 14:32 ` Mathieu Desnoyers
2020-05-26 14:38 ` Florian Weimer [this message]
2020-05-26 14:53 ` Mathieu Desnoyers
2020-05-26 14:57 ` Florian Weimer
2020-05-26 15:22 ` Mathieu Desnoyers
2020-05-01 2:14 ` [PATCH glibc 2/3] glibc: sched_getcpu(): use rseq cpu_id TLS on Linux (v7) Mathieu Desnoyers
2020-05-20 10:14 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftbmpxqi.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=bmaurer@fb.com \
--cc=boqun.feng@gmail.com \
--cc=dalias@libc.org \
--cc=davejwatson@fb.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=pjt@google.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.