Das Argument siginfo_t eines SA_SIGINFO-Handlers

Wenn der Schalter SA_SIGINFO in act.sa_flags angegeben wird, wird die Adresse des Signal-Handlers über das Feld act.sa_sigaction übergeben. Dieser Handler akzeptiert drei Argumente wie folgt:

void
handler(int sig, siginfo_t *info, void *ucontext)
{
    ...
}

Die Bedeutung der drei Argumente im Einzelnen:

sig

Die Anzahl der Signale, die den Aufruf des Handlers hervorriefen.

info

Ein Zeiger auf ein siginfo_t. Dies ist eine Struktur, die weitere Informationen, wie unten beschrieben, über das Signal enthält.

ucontext

Dies ist ein Zeiger auf eine Struktur ucontext_t, typenumgewandelt auf void *. Die Struktur, auf die von diesem Feld gezeigt wird, enthält Signalkontextinformationen, die vom Benutzerraum-Stack durch den Kernel gespeichert wurden; für Details siehe sigreturn(2). Weitere Informationen über die Struktur ucontext_t können in getcontext(3) und signal(7) gefunden werden. Typischerweise verwendet die Handler-Funktion das dritte Argument nicht.

Der Datentyp siginfo_t ist eine Struktur mit den folgenden Feldern:

siginfo_t {
    int      si_signo;     /* Signalnummer */
    int      si_errno;     /* Ein Errno-Wert */
    int      si_code;      /* Signal-Code */
    int      si_trapno;    /* Ausnahmebehandlungsnummer die das Hardware-
                              gestüzte Signal hervorrief
                              (auf den meisten Architekturen unbenutzt) */
    pid_t    si_pid;       /* Senden der Prozesskennung */
    uid_t    si_uid;       /* Echte Benutzerkennung des sendenden Prozesses */
    int      si_status;    /* Exit-Wert oder -Signal */
    clock_t  si_utime;     /* Verbrauchte Benutzerzeit */
    clock_t  si_stime;     /* Verbrauchte Systemzeit */
    union sigval si_value; /* Signalwert */
    int      si_int;       /* POSIX.1b-Signal */
    void    *si_ptr;       /* POSIX.1b-Signal */
    int      si_overrun;   /* Timer-Überlaufzähler;
                              POSIX.1b-Timer */
    int      si_timerid;   /* Timer-Kennung; POSIX.1b-Timer */
    void    *si_addr;      /* Speicherort, der die Ausnahmebehnadlung auslöste */
    long     si_band;      /* Bandeereignis (war int in
                              Glibc 2.3.2 und älter) */
    int      si_fd;        /* Dateideskriptor */
    short    si_addr_lsb;  /* Niedrigstes Bit der Adresse
                              (seit Linux 2.6.32) */
    void    *si_lower;     /* Untere Grenze bei Adresssverletzung
                              aufgetreten (seit Linux 3.19) */
    void    *si_upper;     /* Obere Grenze bei Adresssverletzung
                              aufgetreten (seit Linux 3.19) */
    int      si_pkey;      /* Schutzschlüssel auf PTE der die
                              Ausnahmebehandlung auslöste (seit Linux 4.6) */
    void    *si_call_addr; /* Adresse der Systemaufrufanweisung
                              (seit Linux 3.5) */
    int      si_syscall;   /* Nummer des versuchten Systemaufrufs
                              (seit Linux 3.5) */
    unsigned int si_arch;  /* Architektur des versuchten Systemaufrufs
                              (seit Linux 3.5) */
}

si_signo, si_errno und si_code sind für alle Signale definiert. (si_errno ist im Allgemeinen unter Linux unbenutzt). Der Rest der Struktur kann eine Union sein, daher sollten nur die Felder ausgelesen werden, die für das übergebene Signal von Bedeutung sind:

•

Signale, die mit kill(2) und sigqueue(3) gesandt werden, füllen si_pid und si_uid aus. Zusätzlich füllen Signale, die mit sigqueue(3) gesandt werden, si_int und si_ptr mit den vom Sender angegebenen Werten aus. Siehe sigqueue(3) für weitere Details.

•

Signale, die von POSIX.1b-Timern gesendet werden (seit Linux 2.6), füllen si_overrun und si_timerid. Das Feld si_timerid ist eine interne Kennung, die vom Kernel zur Identifikation des Timers benutzt wurde, sie ist nicht mit der durch timer_create(2) zurückgelieferten Kennung identisch. Das Feld si_overrun ist der Timer-Überlaufzähler. Dies ist die gleiche Information, wie sie durch einen Aufruf von timer_getoverrun(2) erhalten wird. Diese Felder sind nicht standardisierte Linux-Erweiterungen.

•

Signale, die der Nachrichtenbenachrichtigungswarteschlange gesandt werden (siehe die Beschreibung von SIGEV_SIGNAL in mq_notify(3)), füllen si_int/si_ptr, wobei sigev_value für mq_notify(3) bereitgestellt wird, si_pid mit der Prozesskennung des Absenders und si_uid mit der realen Benutzerkennung des Nachrichtensenders.

•

SIGCHLD füllt si_pid, si_uid, si_status, si_utime und si_stime mit Informationen über das Kind aus. Das Feld si_pid ist die Prozesskennung des Kindes; si_uid ist die reale Benutzerkennung. Das Feld si_status enthält den Exit-Status des Kindes (falls si_code CLD_EXITED ist) oder die Signalnummer, die den Prozess zur Zustandsänderung veranlasst hat. si_utime und si_stime enthalten die vom Kindprozess verwandte Benutzer- und System-CPU-Zeit, diese Felder enthalten nicht die Zeit von Kindern, auf die gewartet wurde (anders als getrusage(2) und times(2)). Bis Linux 2.6 und seit Linux 2.6.27 berichten diese Felder die CPU-Zeit in Einheiten von sysconf(_SC_CLK_TCK). In Linux 2.6er-Kerneln vor Linux 2.6.27 wurden durch einen Fehler diese Felder in Einheiten der (konfigurierbaren) System-Jiffys berichtet (siehe time(7)).

•

SIGILL, SIGFPE, SIGSEGV, SIGBUS und SIGTRAP füllen in si_addr die Adresse der Ausnahmebehandlung ein. Auf einigen Architekturen werden diese Signale auch in das Feld si_trapno eingefüllt.

Einige Unterfehler von SIGBUS, insbesondere BUS_MCEERR_AO und BUS_MCEERR_AR, füllen auch si_addr_lsb aus. Dieses Feld zeigt die niedrigste Bit der berichteten Adresse and und somit die größe der Beschädigung. Wurde beispielsweise eine ganze Seite beschädigt, enthält si_addr_lsb contains log2(sysconf(_SC_PAGESIZE)). Wenn SIGTRAP als Antwort auf ein ptrace(2)-Ereignis (PTRACE_EVENT_foo) geliefert wird, dann wird si_addr nicht gefüllt, aber si_pid und si_uid werden mit der respektiven Prozesskennung und Benutzerkennung, die für das Ausliefern der Ausnahmebehandlung verantwortlich sind, gefüllt. Im Falle von seccomp(2) wird das nachverfolgte Programm (»Tracee«) als Auslieferer des Ereignisses angezeigt. BUS_MCEERR_* and si_addr_lsb sind Linux-spezifische Erweiterungen.

Der Unterfehler SEGV_BNDERR von SIGSEGV belegt si_lower und si_upper.

Der Unterfehler SEGV_PKUERR von SIGSEGV belegt si_pkey.

•

SIGIO/SIGPOLL (die zwei Namen sind unter Linux synonym) füllen si_band und si_fd aus. Das Ereignis si_band ist eine Bitmaske, die die gleichen Werte enthält, die auch durch poll(2) in das Feld revents eingetragen werden. Das Feld si_fd zeigt den Dateideskriptor an, für den ein E/A-Ereignis aufgetreten ist. Für weitere Details lesen Sie die Beschreibung von F_SETSIG in fcntl(2).

•

SIGSYS, erstellt (seit Linux 3.5) wenn ein Seccomp-Filter SECCOMP_RET_TRAP zurückliefert, füllt si_call_addr, si_syscall, si_arch, si_errno und andere Felder wie in seccomp(2) beschrieben aus.

Das Feld si_code

Das Feld si_code innerhalb des an den Signal-Handler SA_SIGINFO übergebenen Arguments siginfo_t ist ein Wert (keine Bitmaske), der angibt, warum dieses Signal gesendet wurde. Für ein ptrace(2)-Ereignis wird si_code SIGTRAP enthalten und das Ptrace-Ereignis im hohen Byte enthalten.

(SIGTRAP | PTRACE_EVENT_foo << 8).

Für ein Ereignis außerhalb von ptrace(2) sind die Werte, die in si_code erscheinen können, im Rest dieses Abschnittes beschrieben. Seit Glibc 2.20 werden die Definitionen der meisten dieser Symbole aus <signal.h> erhalten, indem Feature-Test-Makros (vor dem Einbinden irgendeiner Header-Datei) wie folgt definiert werden:

•

_XOPEN_SOURCE mit dem Wert 500 oder größer;

•

_XOPEN_SOURCE und _XOPEN_SOURCE_EXTENDED; oder

•

_POSIX_C_SOURCE mit einem Wert 200809L oder größer.

Für die Konstanten TRAP_* werden die Symboldefinitionen nur in den ersten zwei Fällen bereitgestellt. Vor Glibc 2.20 wurde kein Feature-Test-Makro zum Erhalt dieser Symbole benötigt.

Für ein reguläres Signal zeigt die folgende Liste die Werte, die in si_code für jedes Signal gelegt werden können, zusammen mit dem Grund für die Erstellung des Signals.

Die folgenden Werte können in si_code für ein Signal SIGILL gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGFPE gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGSEGV gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGBUS gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGTRAP gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGCHLD gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGIOSIGPOLL gesetzt werden:

Die folgenden Werte können in si_code für ein Signal SIGSYS gesetzt werden:

Dynamisches Ermitteln für Schalter-Bit-Unterstützung

Unter Linux akzeptiert der Aufruf sigaction() ohne Fehler unbekannte Bits, die in act->sa_flags gesetzt sind. Beginnend mit Linux 5.11 ist das Verhalten, dass ein zweiter Aufruf von sigaction() unbekannte Bits aus oldact->sa_flags bereinigen wird. Allerdings würde historisch ein zweiter Aufruf von sigaction() diese Bits in oldact->sa_flags gesetzt lassen.

Das bedeutet, dass die Unterstützung für neue Schalter nicht einfach dadurch erkannt werden kann, indem auf einen Schalter in sa_flags getestet wird und ein Programm muss testen, dass SA_UNSUPPORTED bereinigt wurde, beovr es sich auf die Inhalte von sa_flags verlassen kann.

Da das Verhalten des Signal-Handlers nicht garantiert werden kann, außer diese Prüfung war erfolgreich, ist es Weise, entweder das betroffene Signal zu blockieren, während der Handler registriert wird und in diesem Fall die Prüfung durchzuführen, oder, wo das nicht möglich ist, beispielsweise falls das Signal synchron ist, einen zweiten sigaction() im Signal-Handler selbst auszulösen.

Bei Kerneln, die einen bestimmten Schalter nicht unterstützen, verhält sich der Kernel so, als ob der Schalter nicht gesetzt worden wäre, selbst wenn der Schalter in act->sa_flags gesetzt wurde.

Die Schalter SA_NOCLDSTOP, SA_NOCLDWAIT, SA_SIGINFO, SA_ONSTACK, SA_RESTART, SA_NODEFER, SA_RESETHAND und, falls durch die Architektur definiert, SA_RESTORER können nicht zuverlässig mittels dieses Mechanismus erkannt werden, da sie vor Linux 5.11 eingeführt wurden. Allerdings können Programme im Allgemeinen annehmen, dass diese Schalter unterstüzt werden, da sie alle seit Linux 2.6, das im Jahr 2003 veröffentlicht wurde, unterstützt werden.

Siehe nachfolgende BEISPIELE für eine Vorstellung des Einsatzes von SA_UNSUPPORTED.

Unterschiede C-Bibliothek/Kernel

Die Glibc-Wrapper-Funktion für sigaction() liefert bei Versuchen, die Zuordnung der zwei intern durch die NPTL-Threading-Implementierung verwandten Echtzeitsignale zu ändern, einen Fehler zurück. Siehe nptl(7) für Details.

Auf Architekturen, bei denen das Signal-Trampolin innerhalb der C-Bibliothek liegt, setzt die Glibc-Wrapper-Funktion für sigaction() die Adresse des Trampolin-Codes in das Feld act.sa_restorer und SA_RESTORER in das Feld act.sa_flags. Siehe sigreturn(2).

Der ursprüngliche Linux-Systemaufruf hieß sigaction(). Mit dem Hinzufügen von Echtzeitsignalen in Linux 2.2 passte der mit einer festen Größe versehene 32-Bit-Typ sigset_t nicht mehr für den Zweck. Daher wurde ein neuer Systemaufruf rt_sigaction() mit einem vergrößerten Typ sigset_t hinzugefügt. Der neue Systemaufruf akzeptiert ein viertes Argument size_t sigsetsize, das die Größe in Bytes der Signalgruppe in act.sa_mask und oldact.sa_mask festlegt. Dieses Argument muss derzeit den Wert sizeof(sigset_t) enthalten oder der Fehler EINVAL tritt auf. Die Glibc-Wrapper-Funktion sigaction() versteckt diese Details und ruft rt_sigaction() transparent auf, wenn der Kernel ihn bereitstellt.

Undokumentiert

Vor der Einführung von SA_SIGINFO war es auch möglich, einige zusätzliche Informationen über das Signal zu erhalten. Dies erfolgte durch Bereitstellung eines sa_handler-Signal-Handlers mit einem zweiten Argument des Typs struct sigcontext, das die gleiche Struktur ist, wie jene, die im Feld uc_mcontext der Struktur ucontext übergeben wird, die wiederum (mittels eines Zeigers) als drittes Argument des Handlers sa_sigaction übergeben wird. Siehe die relevanten Kernelquellen für Details. Diese Verwendung ist jetzt veraltet.

Ermitteln von Schalter-Unterstützung

Das nachfolgende Beispielprogramm beendet sich mit dem Status EXIT_SUCCESS falls bestimmt wird, dass SA_EXPOSE_TAGBITS unterstützt wird, und andernfalls mit EXIT_FAILURE.

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
void
handler(int signo, siginfo_t *info, void *context)
{
    struct sigaction oldact;
    if (sigaction(SIGSEGV, NULL, &oldact) == -1
        || (oldact.sa_flags & SA_UNSUPPORTED)
        || !(oldact.sa_flags & SA_EXPOSE_TAGBITS))
    {
        _exit(EXIT_FAILURE);
    }
    _exit(EXIT_SUCCESS);
}
int
main(void)
{
    struct sigaction act = { 0 };
    act.sa_flags = SA_SIGINFO | SA_UNSUPPORTED | SA_EXPOSE_TAGBITS;
    act.sa_sigaction = &handler;
    if (sigaction(SIGSEGV, &act, NULL) == -1) {
        perror("sigaction");
        exit(EXIT_FAILURE);
    }
    raise(SIGSEGV);
}