ARC vs. generic sigaction (was Re: [PATCH 08/21] ARC: Linux Syscall Interface)

[vineet.gupta1@synopsys.com (Vineet Gupta)]

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)				\
>> + ({								\
>> +   if (!((kact)->sa_flags & SA_RESTORER))			\
>> +     {								\
>> +       (kact)->sa_restorer = __default_rt_sa_restorer;		\
>> +       (kact)->sa_flags |= SA_RESTORER;			\
>> +     }								\
>> +   else							\
>> +     (kact)->sa_restorer = (act)->sa_restorer;			\
>> + })
> What is so special about ARC sa_restorer that an application should provide
> an specialized one?

Its the other way around. Only if application provides it's own restorer, we honor
it, otherwise default restorer is used. This logic goes back many many years ago
to how ARC uClibc did this and likely inherited it from the port it was copied
from. But I don't know if say POSIX allows apps to provide their own restorer or
not. We could very well remove it; although per other discussion if we intend to
use the same struct sigaction for kernel/userland, the placeholder would exist and
we could choose to just ignore it.


> Can't it follow other abi where they issue __NR_sigreturn
> for !SA_SIGINFO or __NR_rt_sigreturn otherwise?

With Linux UAPI ABI, __NR_sigreturn doesn't exist, but your concern is about
restorer ?

> As for other architecture I do think we should hide the sa_restorer usage
> from application.

As mentioned above, the placeholder could exist, we can choose to ignore it.