[PATCH v2 1/2] setjmp: Use BSD sematic as default for setjmp
Adhemerval Zanella Netto
adhemerval.zanella@linaro.org
Tue Jul 23 16:04:47 GMT 2024
On 23/07/24 10:49, Florian Weimer wrote:
> * Adhemerval Zanella:
>
>> POSIX relaxed the relation of setjmp/longjmp and the signal mask
>> save/restore, meaning that setjmp does not require to be routed to
>> _setjmp to be standard compliant.
>>
>> This is done to avoid breakage of SIGABRT handlers, since to fully
>> make abort AS-safe, it is required to remove the recurisve lock
>> used to unblock SIGABRT prior raised the signal.
>>
>> Also, it allows caller to actually use setjmp, since from
>> 7011c2622fe3e10a29dbe74f06aaebd07710127d the symbol is unconditionally
>> routed to _setjmp.
>
> I still don't think making a compatibility-impacting change to fix such
> an obscure bug is a good trade-off.
>
> The kernel providing something like exit_signal (terminate the process
> even if a signal handler is installed) would be a better way forward, in
> my opinion.
What do you mean by obscure bug? The abort not being async-signal-safe is
being triggered by users and incurring in workarounds and time consuming
analysis.
And I don't see the need of a new kernel interface for an issue that can
be complete solved in userspace (and I think kernel developers would say
the same thing, since this most likely will need a new syscall to solve a
very specific userland issue).
And user can still use the SysV setjmp, they just need to explicit say so.
I am not really following the reluctant to fix abort() async-signal-safeness.
More information about the Libc-alpha
mailing list