[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