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: [PATCH] Fix __libc_signal_block_all on sparc64



On 05/12/2019 11:45, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> Where SIGALL_SET is defined as:
>>
>>   ((__sigset_t) { .__val = {[0 ...  _SIGSET_NWORDS-1 ] =  -1 } })
> 
> Shouldn't this refer to a global constant data object?  Then we wouldn't
> have to emit many local copies of the same object and then copy it onto
> the stack.
> 
> (GCC cannot know that the system call will not modify the object.)

Do we really need to add a sigset_t object on ld (it won't require it
any longer since you sent a reverted patch to the signal block on dlopen),
libc, and libpthread?

In fact I think we can simplify it a bit an just get rid of these
block/unblock signals and just use sigprocmask directly. I haven't done
on posix_spawn because the sigprocmask semantic cleared the internal
signals prior issuing rt_sigprocmask. 

However sigfillset already does it, and this is the canonical way to 
operate on sigset_t. The only way to actually broke this assumption
is if caller initialize sigset with memset or something similar, i.e,
bypassing glibc (and again this is not a valid construction imho).

So I what I am thinking is to consolidate the sigprocmask, remove the
SIGCANCEL/SIGSETXID handling (which is not done on all architectures
btw), and replace __libc_signal_block_all, __libc_signal_block_app,
and __libc_signal_restore_set with straight sigprocmask calls.


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