- On Sep 20, 2018, at 4:20 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
>
>> Are you saying glibc has an explicit check for the kernel version visible
>> from /proc before using specific features ? If so, how can this work with
>> the
- On Sep 20, 2018, at 4:20 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
>
>> Are you saying glibc has an explicit check for the kernel version visible
>> from /proc before using specific features ? If so, how can this work with
>> the
On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
> Something like this in pthreadP.h ?
>
> +#ifdef __NR_rseq
> +#include
> +#else
> +#include
> +#endif /* __NR_rseq. */
>
> where sysdeps/unix/sysv/linux/rseq-internal.h contains the linux
> implementation of rseq_register_current_thread () and
On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
> Something like this in pthreadP.h ?
>
> +#ifdef __NR_rseq
> +#include
> +#else
> +#include
> +#endif /* __NR_rseq. */
>
> where sysdeps/unix/sysv/linux/rseq-internal.h contains the linux
> implementation of rseq_register_current_thread () and
On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
> Are you saying glibc has an explicit check for the kernel version visible
> from /proc before using specific features ? If so, how can this work with
> the variety of feature backports we find in the distribution kernels out
> there ?
See
On Thu, 20 Sep 2018, Mathieu Desnoyers wrote:
> Are you saying glibc has an explicit check for the kernel version visible
> from /proc before using specific features ? If so, how can this work with
> the variety of feature backports we find in the distribution kernels out
> there ?
See
- On Sep 19, 2018, at 1:10 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> > This looks like it's coming from the Linux kernel. Can't the relevant
>> > uapi header just be used directly without copying into glibc (with due
>> > care to
- On Sep 19, 2018, at 1:10 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> > This looks like it's coming from the Linux kernel. Can't the relevant
>> > uapi header just be used directly without copying into glibc (with due
>> > care to
- On Sep 19, 2018, at 12:37 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> Here is a rough prototype registering rseq(2) TLS for each thread
>> (including main), and unregistering for each thread (excluding
>> main). "rseq" stands for
- On Sep 19, 2018, at 12:37 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> Here is a rough prototype registering rseq(2) TLS for each thread
>> (including main), and unregistering for each thread (excluding
>> main). "rseq" stands for
On 19/09/18 22:01, Mathieu Desnoyers wrote:
- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
note that libpthread.so is built with -ftls-model=initial-exec
Which would indeed make these annotations redundant. I'll remove
them.
(and if it wasn't then you'd want
On 19/09/18 22:01, Mathieu Desnoyers wrote:
- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
note that libpthread.so is built with -ftls-model=initial-exec
Which would indeed make these annotations redundant. I'll remove
them.
(and if it wasn't then you'd want
- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 19/09/18 15:44, Mathieu Desnoyers wrote:
>> Things to consider:
>>
>> - Move __rseq_refcount to an extra field at the end of __rseq_abi to
>>eliminate one symbol. This would require to wrap struct rseq into
>>
- On Sep 19, 2018, at 1:38 PM, Szabolcs Nagy szabolcs.n...@arm.com wrote:
> On 19/09/18 15:44, Mathieu Desnoyers wrote:
>> Things to consider:
>>
>> - Move __rseq_refcount to an extra field at the end of __rseq_abi to
>>eliminate one symbol. This would require to wrap struct rseq into
>>
- On Sep 19, 2018, at 3:49 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
>
>> i don't think there is precedent for exposing tls symbol in glibc
>> (e.g. errno is exposed via __errno_location function) so there
>> might be issues with this (but i
- On Sep 19, 2018, at 3:49 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
>
>> i don't think there is precedent for exposing tls symbol in glibc
>> (e.g. errno is exposed via __errno_location function) so there
>> might be issues with this (but i
On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
> i don't think there is precedent for exposing tls symbol in glibc
> (e.g. errno is exposed via __errno_location function) so there
> might be issues with this (but i don't have immediate concerns).
There have been suggestions to expose TLS errno - but
On Wed, 19 Sep 2018, Szabolcs Nagy wrote:
> i don't think there is precedent for exposing tls symbol in glibc
> (e.g. errno is exposed via __errno_location function) so there
> might be issues with this (but i don't have immediate concerns).
There have been suggestions to expose TLS errno - but
On 19/09/18 15:44, Mathieu Desnoyers wrote:
Things to consider:
- Move __rseq_refcount to an extra field at the end of __rseq_abi to
eliminate one symbol. This would require to wrap struct rseq into
e.g. struct rseq_lib or such, e.g.:
struct rseq_lib {
struct rseq kabi;
int
On 19/09/18 15:44, Mathieu Desnoyers wrote:
Things to consider:
- Move __rseq_refcount to an extra field at the end of __rseq_abi to
eliminate one symbol. This would require to wrap struct rseq into
e.g. struct rseq_lib or such, e.g.:
struct rseq_lib {
struct rseq kabi;
int
On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
> > This looks like it's coming from the Linux kernel. Can't the relevant
> > uapi header just be used directly without copying into glibc (with due
> > care to ensure that glibc still builds if the kernel headers used for the
> > build are too old -
On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
> > This looks like it's coming from the Linux kernel. Can't the relevant
> > uapi header just be used directly without copying into glibc (with due
> > care to ensure that glibc still builds if the kernel headers used for the
> > build are too old -
- On Sep 19, 2018, at 12:37 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> Here is a rough prototype registering rseq(2) TLS for each thread
>> (including main), and unregistering for each thread (excluding
>> main). "rseq" stands for
- On Sep 19, 2018, at 12:37 PM, Joseph Myers jos...@codesourcery.com wrote:
> On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
>
>> Here is a rough prototype registering rseq(2) TLS for each thread
>> (including main), and unregistering for each thread (excluding
>> main). "rseq" stands for
On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
> Here is a rough prototype registering rseq(2) TLS for each thread
> (including main), and unregistering for each thread (excluding
> main). "rseq" stands for Restartable Sequences.
A final patch would need to add documentation and tests and a NEWS
On Wed, 19 Sep 2018, Mathieu Desnoyers wrote:
> Here is a rough prototype registering rseq(2) TLS for each thread
> (including main), and unregistering for each thread (excluding
> main). "rseq" stands for Restartable Sequences.
A final patch would need to add documentation and tests and a NEWS
26 matches
Mail list logo
