On 12/21/18 4:05 AM, Adhemerval Zanella wrote:
>> Thing is ARC signal return depends on a restorer. Meaning !SA_RESTORER
>> doesn't
>> effectively exist (between libc and kernel). We currently honor user provided
>> value, instead we could simply overwrite it with default_rt_restorer and on
>> th
* Vineet Gupta:
> On 12/20/18 4:40 AM, Florian Weimer wrote:
>> * Adhemerval Zanella:
>>
>>> The only advantage of using a larger sigset_t from glibc standpoint is if
>>> kernel ever change it maximum number of supported signals it would not be
>>> a ABI change (it would be if glibc provided sigse
On 20/12/2018 18:46, Vineet Gupta wrote:
> On 12/20/18 12:06 PM, Adhemerval Zanella wrote:
>>
>>
>> On 20/12/2018 17:23, Vineet Gupta wrote:
>>> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
>> #define SET_SA_RESTORER(kact, act) \
>> (kact)->sa_flags = (act)->sa_f
On 12/20/18 12:06 PM, Adhemerval Zanella wrote:
>
>
> On 20/12/2018 17:23, Vineet Gupta wrote:
>> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
> #define SET_SA_RESTORER(kact, act) \
> (kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
> (kact)->sa_resto
On 20/12/2018 17:23, Vineet Gupta wrote:
> On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
#define SET_SA_RESTORER(kact, act) \
(kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
(kact)->sa_restorer = &__default_rt_sa_restorer
>>> +#define SET_SA_RESTO
On 12/20/18 4:07 AM, Arnd Bergmann wrote:
> All users of sigset_t that I could find in the kernel just check
> the size argument to ensure it matches _NSIG, and return
> EINVAL otherwise.
Indeed that was one of the very first problem ARC glibc port ran into with stock
sizeof(sigset_t) passed in si
On 12/20/18 3:19 AM, Adhemerval Zanella wrote:
>>> #define SET_SA_RESTORER(kact, act) \
>>> (kact)->sa_flags = (act)->sa_flags | SA_RESTORER; \
>>> (kact)->sa_restorer = &__default_rt_sa_restorer
>> +#define SET_SA_RESTORER(kact, act) \
>> + ({
On 12/20/18 4:40 AM, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> The only advantage of using a larger sigset_t from glibc standpoint is if
>> kernel ever change it maximum number of supported signals it would not be
>> a ABI change (it would be if glibc provided sigset_t need to be extended)
* Adhemerval Zanella:
> The only advantage of using a larger sigset_t from glibc standpoint is if
> kernel ever change it maximum number of supported signals it would not be
> a ABI change (it would be if glibc provided sigset_t need to be extended).
It's not just the kernel. We might want to re
On Thu, Dec 20, 2018 at 12:19 PM Adhemerval Zanella
wrote:
> On 19/12/2018 20:23, Vineet Gupta wrote:
> > On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
> >> One possibility is to define an arch-specific __sigset_t.h with a custom
> >> _SIGSET_NWORDS value and add an optimization on Linux sigactio
On 19/12/2018 20:23, Vineet Gupta wrote:
> On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
>>
>>
>> One possibility is to define an arch-specific __sigset_t.h with a custom
>> _SIGSET_NWORDS value and add an optimization on Linux sigaction.c to check
>> if both kernel_sigaction and glibc sigacti
On 12/19/18 2:00 PM, Adhemerval Zanella wrote:
>
>
> One possibility is to define an arch-specific __sigset_t.h with a custom
> _SIGSET_NWORDS value and add an optimization on Linux sigaction.c to check
> if both kernel_sigaction and glibc sigaction share same size and internal
> layout to use t
On 19/12/2018 15:58, Vineet Gupta wrote:
> On 12/18/18 6:39 PM, Vineet Gupta wrote:
diff --git a/sysdeps/unix/sysv/linux/arc/sigaction.c
b/sysdeps/unix/sysv/linux/arc/sigaction.c
>>> Why do you need this, rather than using the unified version (possibly with
>>> a few macros defined f
On Wed, 19 Dec 2018, Vineet Gupta wrote:
> I took a stab at this but not really happy with taking this approach.
>
> (1). Common code assumes disparate kernel and userland sigaction struct even
> though there's no reason for a *new* port to be: its not like all glibc code
> is
> shared/common al
On 12/18/18 6:39 PM, Vineet Gupta wrote:
>>> diff --git a/sysdeps/unix/sysv/linux/arc/sigaction.c
>>> b/sysdeps/unix/sysv/linux/arc/sigaction.c
>> Why do you need this, rather than using the unified version (possibly with
>> a few macros defined first)?
>
> The only syscall ABI requirement is tha
On 12/18/18 3:30 PM, Joseph Myers wrote:
> On Tue, 18 Dec 2018, Vineet Gupta wrote:
>
>> +/* Flush cache(s). */
>> +int
>> +_flush_cache (char *addr, const int nbytes, const int op)
>> +{
>> + return INLINE_SYSCALL (cacheflush, 3, addr, nbytes, op);
>> +}
>> +weak_alias (_flush_cache, cacheflush
On Tue, 18 Dec 2018, Vineet Gupta wrote:
> +/* Flush cache(s). */
> +int
> +_flush_cache (char *addr, const int nbytes, const int op)
> +{
> + return INLINE_SYSCALL (cacheflush, 3, addr, nbytes, op);
> +}
> +weak_alias (_flush_cache, cacheflush)
Can't this use a syscalls.list entry instead of n
Signed-off-by: Vineet Gupta
---
ChangeLog | 12 ++
sysdeps/unix/sysv/linux/arc/cacheflush.c | 29 +++
sysdeps/unix/sysv/linux/arc/clone.S | 100 ++
sysdeps/unix/sysv/linux/arc/jmp_buf-macros.h | 6 +
sysdeps/unix/sysv/linux/arc/kerne
18 matches
Mail list logo
