Exigences dépendantes de l'architecture¶

L'ABI de chaque architecture possède ses propres exigences sur la façon dont les paramètres des appels système sont passés au noyau. Pour les appels système qui ont une fonction d'enveloppe de la glibc (comme par exemple la plupart des appels système), la glibc s'occupe des détails pour copier les arguments dans les bons registres d'une manière adaptée à chaque architecture. Cependant, en utilisant syscall() pour effectuer un appel système, l'appelant peut avoir besoin de gérer certains détails dépendants de l'architecture ; cette exigence est en particulier rencontrée sur certaines architectures 32 bits.

Par exemple, pour l'Embedded ABI (EABI) de l'architecture ARM, une valeur 64 bits (c'est-à-dire un long long) doit être alignée sur une paire de registres paire. Ainsi, en appelant syscall() au lieu de la fonction d'enveloppe fournie par la glibc, l'appel système readahead() devrait être effectué ainsi sur l'architecture ARM avec l'EABI :

syscall(SYS_readahead, fd, 0,


        (unsigned int) (offset & 0xFFFFFFFF),


        (unsigned int) (offset >> 32),


        count);

Comme le paramètre offset est 64 bits, et le premier argument (fd) est passé dans r0, l'appelant doit manuellement découper et aligner la valeur 64 bits afin de la passer dans la paire de registres r2/r3. Cela implique de passer une valeur fantôme dans r1 (le second argument, qui vaut 0). Il faut également veiller à ce que la division respecte les conventions endian (selon l'ABI C de la plateforme).

Des problèmes similaires peuvent survenir sur MIPS avec l'ABI O32, sur PowerPC avec l'ABI 32 bits, et sur Xtensa.

Notez qu'alors que l'ABI parisc C utilise aussi des paires de registres alignés, il utilise une couche shim pour cacher le résultat de l'espace utilisateur.

Les appels système concernés sont fadvise64_64(2), ftruncate64(2), posix_fadvise(2), pread64(2), pwrite64(2), readahead(2), sync_file_range(2) et truncate64(2).

Cela n'affecte pas les appels système qui séparent et assemblent manuellement les valeurs 64 bits telles que _llseek(2), preadv(2), preadv2(2), pwritev(2) et pwrite2(2). Bienvenue dans le monde fanstastique du bagage historique.

Conventions d'appel par architecture¶

Chaque architecture possède sa façon propre d'invoquer et de passer des paramètres au noyau. Les détails pour diverses architectures sont donnés dans les deux tableaux ci-dessous.

Le premier tableau liste l'instruction utilisée pour passer en mode noyau (qui n'est pas forcément la méthode la meilleure ou la plus rapide, vous devriez consulter vdso(7)), le registre (ou les registres) utilisé(s) pour indiquer le numéro de l'appel système, et le registre utilisé comme code de retour de l'appel système, et le registre utilisé pour signaler une erreur.

Notes :

•

Sur quelques architectures, un registre est utilisé comme un boléen (0 indiquant aucune erreur et -1 indiquant une erreur) pour signaler que l'appel système a échoué. La valeur de l'erreur actuelle est toujours contenue dans le registre renvoyé. Sur sparc, le bit de transport (carry bit, csr) dans le registre d'état du processeur (psr) est utilisé au lieu d'un registre entier. Sur powerpc64, le bit de débordement (overflow bit) sommaire (SO) dans le champ 0 du registre de condition (cr0) est utilisé.

•

NR est le numéro de l'appel système.

•

Pour s390 et s390x, NR (le numéro de l'appel système) peut être passé directement avec svc NR s'il est inférieur à 256.

•

Sur SuperH, des numéros de capture (« trap ») supplémentaires sont pris en charge pour des raisons historiques mais trapa#31 est l'ABI « unifiée » recommandée.

•

Les ABI x32 partagent la table syscall avec l'ABI x86-64, mais avec quelques nuances :

•

Quelques architectures (nommément : Alpha, IA-64, MIPS, SuperH, sparc/32 et sparc/64) utilisent un registre additionnel (« Retval2 » dans la table ci-dessus) pour renvoyer une deuxième valeur de renvoi de l'appel système pipe(2) ; Alpha utilise aussi cette technique pour les appels système getxgid(2), getxuid(2) et getxpid(2) spécifiques à l'architecture. Les autres architectures n'utilisent pas le registre de la seconde valeur renvoyée dans l'interface de l'appel système, même s'il est défini dans l'ABI de System V.

Le second tableau montre les registres utilisés pour passer les paramètres de l'appel système.

Notes :

•

La convention d'appel système mips/o32 passe les arguments 5 à 8 sur la pile utilisateur.

Notez que ces tableaux ne couvrent pas l'ensemble des conventions d'appel système, certaines architectures peuvent écraser sans distinction d'autres registres non listés ici.