This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sigset_t for new arches



On 13/11/2017 22:09, Vineet Gupta wrote:
> On 11/13/2017 03:18 PM, Joseph Myers wrote:
>> On Mon, 13 Nov 2017, Vineet Gupta wrote:
>>
>>> Hi,
>>>
>>> This came to light when initial testing ARC port to glibc.
>>>
>>> ARC glibc sigaction wrapper was failing as Linux kernel expects sa_mask
>>> (sigset_t) to be 2 words (for the asm-generic syscall ABI mandated for newer
>>> arches) while glibc defines it to be 32 words.
>> I think the userspace sigset_t is deliberately much larger, to allow for
>> possible increase in the number of signals in future without breaking the
>> glibc ABI.
> 
> But a new signal added would imply an ABI change anyways ? Anyhow it seems H.J has some bits in flight which seem to tend to this for setjmp/longjmp atleast.
> My concern was to elide any extraneous user-to-kernel (and vice versa) copies in frequently uses syscallas such as sigaction, for which even the new code needs to use these NSIG / 8 hacks lookalike (vs. using well defined interface / macros).
> 
> -Vineet

A new signal that might extend sa_mask will most likely require kernel
support, either by providing a new syscall or by extending current one
and requiring userspace to advertise it (by using a new flag in sa_flags
for instance). In any case by having a dissociated structure from the
kernel allows programs to not be affected since it will be the syscall
wrapper (sigaction) that will handle this transparently.

If we now change sigset_t to a different size it will require have
different sizes depending of the architecture (which itself is not
an issue but add complexity in glibc code) and we will need to add
compatibility symbols to handle the old sizes (more complexity).

I hardly consider sigaction to be a hostspot in any application and
the memory copied required to such call should be negligible (152
bytes per call). Also I am working on consolidate all sigaction.c
implementation, so I suggest you to avoid add a ARC specific one
and focus on using sysdeps/unix/sysv/linux/sigaction.c.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]