15488a7f78
The POSIX standard [POSIX.1-2024](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap01.html#tag_18) specifies how the utility reacts to signals as follows. This includes clang when invoke through a invocation such as [c17](https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html) ``` ASYNCHRONOUS EVENTS The ASYNCHRONOUS EVENTS section lists how the utility reacts to such events as signals and what signals are caught. Default Behavior: When this section is listed as "Default.", or it refers to "the standard action" for any signal, it means that the action taken as a result of the signal shall be as follows: If the action inherited from the invoking process, according to the rules of inheritance of signal actions defined in the System Interfaces volume of POSIX.1-2024, is for the signal to be ignored, the utility shall ignore the signal. If the action inherited from the invoking process, according to the rules of inheritance of signal actions defined in System Interfaces volume of POSIX.1-2024, is the default signal action, the result of the utility's execution shall be as if the default signal action had been taken. When the required action is for the signal to terminate the utility, the utility may catch the signal, perform some additional processing (such as deleting temporary files), restore the default signal action, and resignal itself. ``` This PR updates the LLVM/Clang’s behavior accordingly by not installing a signal handler when the inherited disposition is `SIG_IGN`, and by ensuring that the exit code reflects the terminating signal number, resignaling after the signal is handled. Additionally, test cases have been updated to expect failures due to signals/crashes rather than regular errors. [<signal.h>](https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/signal.h.html) specifies the default action of signals.
llvm/lib/Support/Unix README =========================== This directory provides implementations of the lib/System classes that are common to two or more variants of UNIX. For example, the directory structure underneath this directory could look like this: Unix - only code that is truly generic to all UNIX platforms Posix - code that is specific to Posix variants of UNIX SUS - code that is specific to the Single Unix Specification SysV - code that is specific to System V variants of UNIX As a rule, only those directories actually needing to be created should be created. Also, further subdirectories could be created to reflect versions of the various standards. For example, under SUS there could be v1, v2, and v3 subdirectories to reflect the three major versions of SUS.