* Mathieu Desnoyers:
quoted
Can you use __has_include in <sys/rseq.h>, with a copy of the kernel
definitions if the kernel header is not available?
Sure. Should I pull a verbatim copy of uapi linux/rseq.h into glibc ?
If so, where should I put it ?
Probably into <sys/rseq.h>, perhaps with a construct like this
(untested):
#ifdef __has_include
# if __has_include ("linux/rseq.h")
# define __GLIBC_HAVE_KERNEL_RSEQ
# endif
#else
# include <linux/version.h>
# if LINUX_VERSION_CODE >= KERNEL_VERSION (4, 18, 0)
# define __GLIBC_HAVE_KERNEL_RSEQ
# endif
#endif
#ifdef __GLIBC_HAVE_KERNEL_RSEQ
# include <linux/rseq.h>
#else
… (fallback goes here)
#endif
We have an ongoing debate whether the fallback definition should use
__u64 or uint64_t.
You also need to add an assert that the compiler supports
__attribute__ ((aligned)) because ignoring it produces an
ABI-incompatible header. The struct rseq/struct rseq_cs definitions
are broken, they should not try to change the alignment.
PS: I have Internet connection trouble. Nobody should be worried if I
drop off the net for a while. I understand this is quite a bad time
for that. 8-(
----- On Mar 19, 2020, at 12:03 PM, Florian Weimer fw@deneb.enyo.de wrote:
* Mathieu Desnoyers:
quoted
quoted
Can you use __has_include in <sys/rseq.h>, with a copy of the kernel
definitions if the kernel header is not available?
Sure. Should I pull a verbatim copy of uapi linux/rseq.h into glibc ?
If so, where should I put it ?
Probably into <sys/rseq.h>, perhaps with a construct like this
(untested):
#ifdef __has_include
# if __has_include ("linux/rseq.h")
# define __GLIBC_HAVE_KERNEL_RSEQ
# endif
#else
# include <linux/version.h>
# if LINUX_VERSION_CODE >= KERNEL_VERSION (4, 18, 0)
# define __GLIBC_HAVE_KERNEL_RSEQ
# endif
#endif
#ifdef __GLIBC_HAVE_KERNEL_RSEQ
# include <linux/rseq.h>
#else
… (fallback goes here)
#endif
OK will do.
We have an ongoing debate whether the fallback definition should use
__u64 or uint64_t.
Then I'll keep including <linux/types.h> in the fallback and use
__u{32,64} for now. If this proves to be an issue we can change it later.
This is the minimal change from the uapi header.
You also need to add an assert that the compiler supports
__attribute__ ((aligned)) because ignoring it produces an
ABI-incompatible header.
Are you aware of some helper macro I should use to do this, or
is it done elsewhere in glibc ?
The struct rseq/struct rseq_cs definitions
are broken, they should not try to change the alignment.
AFAIU, this means we should ideally not have used __attribute__((aligned))
in the uapi headers in the first place. Why is it broken ? However, now
that it is in the wild, it's a bit late to change that.
PS: I have Internet connection trouble. Nobody should be worried if I
drop off the net for a while. I understand this is quite a bad time
for that. 8-(
Allright, thanks for the heads up! Stay safe!
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com