Le document System V AMD64 psABI est conservé en tant que sources LaTeX sur GitLab. De même, le psABI i386 est un référentiel GitLab distinct. (Anciennement sur github). Ces pages contiennent des informations sur les endroits où les révisions sont discutées.
L'ABI x32 (pointeurs 32 bits en mode long) fait partie de la doc x86-64 alias AMD64 ABI. Voir Chapitre 10 :Modèle de programmation ILP32.
Le dépôt GitLab construit automatiquement un PDF de la version x86-64 actuelle , mais pas i386.
Voir aussi le wiki des balises x86 pour d'autres guides/références/liens.
La dernière version sur Github était le brouillon x86-64 version 1.0 (janvier 2018). En juillet 2022, la version actuelle est toujours la 1.0, le mot Brouillon étant supprimé fin 2018.
Github héberge également un PDF de i386 ABI version 1.1.
(Notez que la plupart des systèmes d'exploitation non-Linux utilisent une ancienne version de l'ABI i386 qui ne nécessite pas d'alignement de pile de 16 octets, seulement 4. GCC a fini par dépendre de -mpreferred-stack-boundary=4 Alignement sur 16 octets pour son code-gen SSE (peut-être involontairement), et finalement l'ABI a été mis à jour pour Linux pour en faire une exigence officielle. J'ai tenté un résumé dans un commentaire sur le bogue GCC #40838. Cela rompt la compatibilité avec certains asm écrits à la main qui appellent d'autres fonctions.)
Officieusement, l'extension des arguments étroits à 32 bits est requise (pour i386 et amd64), car clang en dépend. Espérons qu'une future révision de l'ABI documentera cela. GCC et/ou clang ont maintenant quelques options pour contrôler cela (TODO déterre comment ils s'appelaient), mais la valeur par défaut est toujours la même à partir de 2022.
Nom :psABI
Le supplément du processeur (psABI) sont conçues comme un complément à la gABI System V (générique) moins fréquemment mise à jour, hébergée sur le site Web de SCO.
Autres liens
Aussi https://refspecs.linuxfoundation.org/ héberge une copie du gABI de 1997.
https://uclibc.org/specs.html contient des liens psABI pour divers ISA non x86. (Bien que, par exemple, celui d'ARM ne semble documenter que la disposition du fichier ELF, pas la convention d'appel ou l'état de démarrage du processus.) https://uclibc.org/docs/psABI-x86_64.pdf est une copie obsolète du x86-64 psABI (0,99,7 à partir de 2014). La version sur GitHub a une formulation plus claire de certaines choses et des corrections de bugs dans certains exemples.
En relation :Quelles sont les conventions d'appel pour les appels système UNIX et Linux (et les fonctions de l'espace utilisateur) sur i386 et x86-64 décrit la convention d'appel système pour x86-64 SysV (ainsi que i386 Linux contre FreeBSD).
Il résume également les conventions d'appel de fonction pour les arguments entiers. Les appels système ne prennent pas les arguments vectoriels FP ou SSE/AVX, ni les structures par valeur, de sorte que la convention d'appel de fonction est plus compliquée.
Agner Fog a un guide des conventions d'appel (couvrant Windows par rapport à Sys V, et les diverses conventions pour 32 bits, et des conseils/astuces pour écrire des fonctions que vous pouvez utiliser sur l'une ou l'autre plate-forme). Il s'agit d'un PDF distinct de ses guides d'optimisation et de microarchitecture et de ses tableaux d'instructions (qui sont une lecture essentielle si vous vous souciez des performances.)
Wikipedia a un article sur les conventions d'appel x86 qui décrit diverses conventions, mais généralement pas assez en détail pour les utiliser pour autre chose que de simples arguments entiers. (par exemple, aucune description des règles de struct-packing).
Connexe :C++ ABI
GCC et Clang (sur toutes les architectures) utilisent l'ABI C++ développée à l'origine pour Itanium. https://itanium-cxx-abi.github.io/cxx-abi/. Ceci est pertinent par exemple pour les exigences qu'une structure/classe C++ doit être transmise dans des registres (par exemple, être un agrégat selon une définition), par rapport à lorsqu'une structure/classe doit toujours avoir une adresse et être transmise par référence, même quand il est assez petit pour être emballé dans 2 registres. Ces règles dépendent de choses ayant un constructeur ou un destructeur non trivial.
Base standard Linux
La base standard Linux, qui peut être considérée par certains comme la spécification faisant autorité en la matière, a une section appelée 7.2. "Function Calling Sequence" pointe vers le 2.1. "Section Références normatives" qui contient les liens suivants :
- Interface binaire d'application System V, édition 4.1 http://www.sco.com/developers/devspecs/gabi41.pdf
- Interface binaire d'application System V - BROUILLON - 17 décembre 2003 http://www.sco.com/developers/gabi/2003-12-17/contents.html
- Supplément du processeur d'architecture AMD64 de l'interface binaire d'application System V, version provisoire 0.95 http://refspecs.linux-foundation.org/elf/x86_64-abi-0.95.pdf
Je recommanderais donc d'utiliser ces versions des spécifications comme versions canoniques, sauf si vous avez une bonne raison de faire autrement.
La version actuelle de l'System V ABI de GitLab peut être facilement transformé en un joli PDF avec ces étapes, en supposant un système Ubuntu.
sudo apt-get install texlive-full
git clone https://gitlab.com/x86-psABIs/x86-64-ABI
cd x86-64-ABI
make pdf
Cela produira un fichier appelé abi.pdf qui est celui-là même qui est nécessaire, comme ci-dessous.
Notez que la date dans le titre semble être la date de construction du PDF plutôt que la date réelle de la dernière modification du document.
