Quelles sont les conventions d'appel pour les appels système UNIX et Linux sous x86-64

Question

Explique les conventions d’appel système UNIX (type BSD) et Linux pour x86-32:

• http://www.int80h.org/bsdasm/#system-calls

• http://www.freebsd.org/doc/en/books/developers-handbook/x86-system-calls.html

Quelqu'un peut-il me dire ou m'indiquer un document similaire pour x86-64 sous UNIX et Linux?

Answer 1

J'ai vérifié à l'aide de ces Assembleur GNU (gaz) sur Linux.

Interface De Noyau

x86-32 Appel Système Linux convention:

En x86-32 paramètres pour l'appel système linux sont transmis à l'aide de registres. %eax pour syscall_number %ebx, %ecx, %edx, %esi, %edi, %ebp sont utilisés pour le passage des 6 paramètres d'appels système.

J'ai pris suivant extrait de l' Linux Assemblée Tutoriel mais je doute à ce sujet. Si quelqu'un peut montrer un exemple. Il serait grand.

Si il y a plus de six arguments, %ebx doit contenir la mémoire emplacement de la liste d'arguments est stocké mais ne vous inquiétez pas à propos de ce parce qu'il est peu probable que vous allez utiliser un syscall avec plus de six les arguments.

Pour un exemple et un peu plus de lecture, reportez-vous à http://www.int80h.org/bsdasm/#alternate-calling-convention

x86-32 [Gratuit|Open|Net|DragonFly]BSD UNIX Système de convention d'Appel:

Les paramètres sont passés sur la pile. Poussez les paramètres (dernier paramètre poussé en premier) sur la pile. Puis poussez un supplément de 32 bits de données factices (ce n'est pas réellement des données factices. reportez-vous au lien suivant pour plus d'info), puis donner un système d'appel d'instruction int $0x80

http://www.int80h.org/bsdasm/#default-calling-convention

x86-64 Linux & DragonFly BSD Système de convention d'Appel:

reportez-vous à la section: "A. 2 AMD64 Linux Kernel Conventions" de System V Interface Binaire pour l'Architecture AMD64 Processeur Supplément

Voici l'extrait de cet article:

1. Au niveau de l'utilisateur des applications de l'utiliser comme un entier registres pour le passage de la séquence de %de l'aqr, %rsi, %rdx, %rcx, %r8 et %r9. Le noyau de l'interface utilise %de l'aqr, %rsi, %rdx, %r10, %r8 et %r9.
2. Un appel-système se fait via le syscall instruction. Le noyau détruit les registres %rcx et %r11.
3. Le numéro de la syscall doit être passé dans le registre %rax.
4. Appels-système sont limitées à six arguments, aucun argument n'est passé directement sur la pile.
5. De retour de la syscall, registre %rax contient le résultat de l'appel-système. Une valeur dans l' gamme entre -4095 et de -1 indique une erreur, c'est -errno.
6. Seules les valeurs de la classe entière ou de classe de la MÉMOIRE sont passés au noyau.

x86-64 [Gratuit|Open|Net]BSD UNIX Système de convention d'Appel:

Le fichier source ia64/ia64/syscall.S est commenté et contient à la fois de la passerelle et les procédures de retour.

Interface Utilisateur

x86-32 Fonction de convention d'Appel:

En x86-32 paramètres ont été passés sur la pile. dernier paramètre a été poussé en premier sur la pile jusqu'à ce que tous les paramètres sont fait et puis call instruction a été exécutée. Ce est utilisé pour l'appel de la bibliothèque C (libc) fonctionne sous linux à partir d'assemblée.

x86-64 Fonction de convention d'Appel:

Je suppose en raison de la raison que nous avons tant de nombreux registres et de la hausse de la largeur d'autres registres de la fonction qui appelle le mécanisme est changé. Dans ce nouveau mécanisme. D'abord les paramètres sont divisés en classes. La classe de chaque paramètre détermine la manière dont il est transmis à la fonction appelée.

Pour des informations complètes, consultez : "3.2 la Fonction de Séquence d'Appel" de System V Interface Binaire pour l'Architecture AMD64 Processeur Supplément qui se lit en partie:

Une fois que les arguments sont classés, l' les registres sont assignés (en de gauche à droite) pour passer comme suit:

1. Si la classe est la MÉMOIRE, passer l'argument sur la pile.
2. Si la classe est de type ENTIER, la prochaine registre de l' séquence de %de l'aqr, %rsi, %rdx, %rcx, %r8 et %r9 est utilisé

donc, %rdi, %rsi, %rdx, %rcx, %r8 and %r9 sont des registres dans l'ordre utilisé pour passer des paramètres à toute la libc fonction de l'assemblage. %de l'aqr est utilisé pour le premier paramètre. %rsi pour la 2ème, %rdx pour la 3ème et ainsi de suite. Ensuite, call enseignement doit être donné.

Si des paramètres sont plus de 6 puis 7 paramètre de partir est passés sur la pile.

Answer 2

Vous recherchez peut-être le ABI x86_64?

• www.x86-64.org/documentation/abi.pdf

Si ce n'est pas précisément ce que vous recherchez, utilisez "x86_64 abi" dans votre moteur de recherche préféré pour trouver des références alternatives.

Answer 3

En général, vous vous inquiétez à propos de tous ces ABI convention que lorsque u est écrit dans l'assemblée. Si non, alors le compilateur en général de suivre l'ABI convention et de concocter l'assemblée dans l'ordre correct pour vous.

Le x86_64 AMD ABI est également suivi par Solaris:

http://developers.sun.com/solaris/articles/about_amd64_abi.html

et donc le partage de tous ceux GCC utilitaires entre les OS sera facile.

Plusieurs fois, j'oublie toujours tous ces détails concrets. Mais pour confirmer ces informations est facile: il suffit de démonté l'utilisateur et le noyau de fichiers binaires et de u peut facilement identifier la répétition et de la différence: dans (Linux) noyau de l'utilisation des piles est peu utilisé, et en application de l'utilisateur, il est toujours utilisé - de la commande des registres est montré facilement dans le démontage.

Oui, la performance est l'une des raisons de ces ABI.

Pour ARM, il existe différents ABI:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html

Pour Linux sur PowerPC:

http://refspecs.freestandards.org/elf/elfspec_ppc.pdf

http://www.0x04.net/doc/elf/psABI-ppc64.pdf

Et pour l'embarqué, il est le EABI etc.....

Answer 4

Outre le lien fourni par Jonathan Leffler dans sa réponse, les conventions d'appel d' Agner Fog en pdf peuvent également vous être utiles.