Quelles sont les conventions d'appel pour UNIX & appels système Linux sur les architectures i386 et x86-64

Liens suivants expliquer x86-32 système de conventions d'appel pour UNIX (BSD saveur) & Linux:

Mais quels sont les x86-64 système de conventions d'appel sur UNIX & Linux?

Il n'y a pas de "norme" pour Unix conventions d'appel. Pour linux sûr, mais je suis sûr que Solaris, OpenBSD, Linux et Minix probablement différents au moins légèrement différentes conventions d'appel et ils sont tous les unix.
Ce n'est pas tout à fait vrai - il y a un ensemble de UNIX ABIs disponibles pour la plupart des types de machines, ce qui permet de les compilateurs C pour réaliser l'interopérabilité. Compilateurs C++ avez un gros problème.
Les deux d'entre vous sont corrects. Je suis à la recherche pour FreeBSD & Linux.
Je vous serais reconnaissant si la réponse contient des informations sur quels registres sont conservés à travers les appels système. Bien sûr, le pointeur de pile est, (à moins que modifié de manière contrôlée dans l' __NR_clone d'appel), mais qui sont les autres?
oui, je viens de mettre à jour le wiki réponse avec les détails pour les 32 bits. 64bit était déjà exacte: rcx et r11 sont détruites à cause de la façon sysret travaux, ainsi que les rax être remplacé par la valeur de retour. Tous les autres registres sont conservés sur amd64.

OriginalL'auteur claws | 2010-03-29

  1. 199

    Autres lectures pour l'un des sujets abordés ici: Le Guide de référence pour Linux Appels Système

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

    Interface De Noyau

    x86-32 aka i386 Linux Système de convention d'Appel:

    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.

    La valeur de retour est dans %eax. Tous les autres registres (y compris EFLAGS) sont conservées dans l' int $0x80.

    J'ai pris l'extrait de code suivant à partir de la Linux Assemblée Tutoriel mais je doute à ce sujet. Si quelqu'un peut montrer un exemple, ce serait formidable.

    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. Un autre exemple d'un Hello World pour i386 Linux à l'aide de int 0x80: Quelles sont les parties de ce HelloWorld assemblée de code sont essentiels si je devais écrire le programme à l'assemblée?

    Il y a un moyen plus rapide pour faire de 32 bits du système d'appels: à l'aide de sysenter. Le noyau des cartes d'une page de la mémoire de chaque processus (le vDSO), avec l'espace utilisateur côté de la sysenter la danse, de coopérer avec le noyau pour être en mesure de trouver l'adresse de retour. Arg pour enregistrer de la cartographie est la même que pour int $0x80. Normalement vous devriez appeler le vDSO au lieu d'utiliser sysenter directement. (Voir Le Guide de référence pour Linux Appels Système pour plus d'informations sur la liaison et l'appel à la vDSO, et pour plus d'infos sur sysenter, et tout le reste à faire avec des appels système.)

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

    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 Système de convention d'Appel:

    x86-64 Mac OS X est similaire, mais différent. TODO: vérifier ce que les *BSD.

    Reportez-vous à la section: "A. 2 AMD64 Linux Noyau Conventions" de Système V-Application Binary Interface pour l'Architecture AMD64 Processeur Supplément. Les versions les plus récentes de la i386 et x86-64 V psABIs peut être trouvé lié depuis cette page dans l'ABI du responsable de repo. (Voir aussi le x86 la balise wiki pour up-to-date ABI liens et beaucoup d'autres bonnes choses à propos de l'asm x86.)

    Voici l'extrait de cet article:

    1. Utilisateur des applications au niveau de l'utilisation, en tant qu'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. Cette clobbers %rcx et %r11 ainsi que le %rax valeur de retour, mais d'autres registres sont conservés.
    3. Le numéro de la syscall doit être passé dans le registre %rax.
    4. Système-les appels sont limités à 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'intervalle entre -4095 et de -1 indique
      une erreur, c'est -errno.
    6. Seulement les valeurs de la classe entière ou de classe de la MÉMOIRE sont passés au noyau.

    Rappelez-vous ceci est du Linux spécifiques de l'annexe à l'ABI, et même pour Linux, il est instructif de ne pas normatif. (Mais en fait, c'est exact.)

    Ce 32-bit int $0x80 ABI est utilisable dans de code 64 bits (mais pas fortement recommandé). Qu'advient-il si vous utilisez la version 32 bits de type int 0x80 ABI Linux en 64 bits de code? Il tronque toujours ses entrées à 32 bits, donc il ne convient pas pour les pointeurs, et il zéros r8-r11.

    De l'Interface utilisateur: la fonction d'appel

    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.

    Versions modernes du Système i386 V ABI (sur Linux) exiger de 16 octets alignement de %esp avant un call, comme le x86-64 V ABI a toujours nécessaire. Callees sont autorisés à assumer et à utiliser de l'ESS de 16 octets charges/magasins que faute non alignés. Mais historiquement, Linux seulement 4 octets de la pile de l'alignement, donc il a fallu un travail supplémentaire pour la réserve naturelle alignés de l'espace, même pour un octet de 8 double ou quelque chose.

    Quelques autres modernes, les systèmes 32 bits ne nécessite pas plus de 4 octets de la pile de l'alignement.

    x86-64 V de l'espace utilisateur de la Fonction de convention d'Appel:

    x86-64 V passe arguments dans les registres, ce qui est plus efficace que le Système i386 V pile args convention. Il évite le temps de latence et les instructions supplémentaires de stockage args à la mémoire (cache), puis de les charger de nouveau le destinataire de l'appel. Cela fonctionne bien parce qu'il y a plus de registres disponibles, et il est mieux pour moderne de haute performance Cpu où la latence et de l'exécution de la matière. (I386 ABI est très ancienne).

    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 Système V-Application Binary Interface pour l'Architecture AMD64 Processeur Supplément qui se lit en partie comme suit:

    Une fois les arguments sont classés, les registres sont attribuées (en
    de gauche à droite) pour le passage 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 les registres afin utilisé pour transmettre entier/pointeur (c'est à dire classe INTEGER) paramètres à tout libc fonction de l'assemblage. %de l'aqr est utilisé pour le premier paramètre de type ENTIER. %rsi pour la 2ème, %rdx pour la 3ème et ainsi de suite. Puis call l'enseignement doit être donné. La pile (%rsp) doit être 16B-alignés lorsqu' call exécute.

    Si il y a plus de 6 paramètres ENTIERS, le 7e paramètre de type ENTIER et, plus tard, sont passés sur la pile. (Appelant pop, de même que les x86-32.)

    Les 8 premiers à virgule flottante les arguments sont passés en %xmm0-7, plus tard, sur la pile. Il n'y a pas d'appel préservé vecteur de registres. (Une fonction avec un mélange de FP et les arguments entiers pouvez avoir plus de 8 total du registre des arguments.)

    Variadic fonctions (comme printf) toujours besoin %al = le nombre de FP registre args.

    Il y a des règles pour savoir quand pack structures dans des registres (rdx:rax sur le retour) par rapport à la mémoire. Voir l'ABI pour plus de détails, et de vérifier la sortie du compilateur pour vous assurer que votre code est d'accord avec les compilateurs sur la façon dont quelque chose doit être transmis/retournés.

    Noter que Windows x64 fonction de convention d'appel a plusieurs différences significatives de x86-64 V, comme l'ombre de l'espace que doit être réservés par l'appelant (au lieu d'une zone rouge), et de l'appeler préservé xmm6-xmm15. Et très différentes règles dont l'arg va dans quel registre.

    Dans linux 32 "tous les registres, à l'exception ax bx cd dx si di bp sont préservés". Je ne peux pas penser à tout ...
    Sur amd64, si il y a plus de 6 paramètres et ils sont passés sur la pile, qui est responsable du nettoyage de la pile après l'appel, l'appelant ou l'appelé?
    appelant nettoie la pile. J'ai mis à jour la réponse avec plus de détails sur la fonction-convention d'appel.
    Si vous utilisez Linux int 0x80 ABI en 64-bits de code, c'est exactement ce qui se passe: stackoverflow.com/questions/46087730/.... Il zéros r8, r11, et fonctionne exactement comme lorsque vous exécutez dans un processus 32 bits. Dans ce Q&j'ai un exemple montrant de travail, ou à défaut avec la troncature d'un pointeur. Et j'ai aussi creusé dans le noyau de la source de montrer pourquoi il se comporte de cette façon.
    L'extrait de code (texte cité) est dans le lien donné Linux Assemblée Tutoriel plus précisément dans la section 4.3 Système Linux Appels

    OriginalL'auteur

  2. 15

    Peut-être vous êtes à la recherche pour le x86_64 ABI?

    Si ce n'est pas précisément ce que vous êtes après, utiliser 'x86_64 abi' dans votre moteur de recherche préféré pour trouver d'autres références.

    en fait, je suis le seul à vouloir le Système de convention d'Appel. l'esp pour UNIX (FreeBSD)
    le système de convention d'appel est une partie de l'ABI.
    ouais. Je suis allé à chaque OS du noyau du développement de l'irc et leur a demandé sur. Ils m'avez dit de regarder dans la source et la figure. Je ne comprends pas sans documenter trucs comment peuvent-ils juste de commencer à développer? Donc, j'ai ajouté une réponse à partir des infos que j'ai recueillies, en espérant d'autres pour compléter le reste des détails.
    le lien semble ne pas fonctionner maintenant. Si vous êtes également un problème visitant le lien, pouvez vous s'il vous plaît mettre à jour?
    Merci pour le heads up; j'ai ajouté un lien vers la Wayback Machine d'enregistrement. L'ensemble x86-64.org site web n'a pas répondu à toutes les données.

    OriginalL'auteur Jonathan Leffler

  3. 11

    Conventions d'appel définit la façon dont les paramètres sont passés dans les registres lors de l'appel ou d'être appelé par un autre programme. Et la meilleure source de ces convention est sous la forme d'ABI standards définis pour chacun de ces matériels. Pour faciliter la compilation, la même ABI est également utilisé par l'utilisateur et le noyau du programme. Linux/Freebsd suivez la même ABI pour x86-64 et un autre ensemble pour 32-bit. Mais x86-64 ABI pour Windows est différente de Linux/FreeBSD. Et généralement ABI ne fait pas de distinction de l'appel système vs normale "des appels de fonctions".
    C'est à dire, ici, est un exemple particulier de x86_64 conventions d'appel et il est le même pour les deux Linux de l'espace utilisateur et noyau: http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/ (notez la séquence a,b,c,d,e,f de paramètres):

    Quelles sont les conventions d'appel pour UNIX & appels système Linux sur les architectures i386 et x86-64

    La Performance est l'une des raisons de ces ABI (par exemple, passage de paramètres via les registres au lieu de les enregistrer dans la mémoire des piles)

    Pour ARM, il existe différents ABI:

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

    https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/iPhoneOSABIReference.pdf

    ARM64 convention:

    http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf

    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 y a de la PPC EABI:

    http://www.freescale.com/files/32bit/doc/app_note/PPCEABI.pdf

    Ce document est bon aperçu de toutes les différentes conventions:

    http://www.agner.org/optimize/calling_conventions.pdf

    Totalement à côté du sujet. L'affiche de la question n'est pas de demander pour le 64 bits syscall convention d'appel dans linux si c'était le même que le général ABI conversions.
    Système V (Linux) ABI sont situé à refspecs.linuxbase.org

    OriginalL'auteur Peter Teoh

  4. 3

    Noyau Linux 5.0 source commentaires

    Je savais que x86 spécificités sont sous arch/x86, et que syscall choses sous arch/x86/entry. Ainsi, une rapide git grep rdi dans ce répertoire me conduit à arch/x86/entrée/entry_64.S:

    /*
 * 64-bit SYSCALL instruction entry. Up to 6 arguments in registers.
 *
 * This is the only entry point used for 64-bit system calls.  The
 * hardware interface is reasonably well designed and the register to
 * argument mapping Linux uses fits well with the registers that are
 * available when SYSCALL is used.
 *
 * SYSCALL instructions can be found inlined in libc implementations as
 * well as some other programs and libraries.  There are also a handful
 * of SYSCALL instructions in the vDSO used, for example, as a
 * clock_gettimeofday fallback.
 *
 * 64-bit SYSCALL saves rip to rcx, clears rflags.RF, then saves rflags to r11,
 * then loads new ss, cs, and rip from previously programmed MSRs.
 * rflags gets masked by a value from another MSR (so CLD and CLAC
 * are not needed). SYSCALL does not save anything on the stack
 * and does not change rsp.
 *
 * Registers on entry:
 * rax  system call number
 * rcx  return address
 * r11  saved rflags (note: r11 is callee-clobbered register in C ABI)
 * rdi  arg0
 * rsi  arg1
 * rdx  arg2
 * r10  arg3 (needs to be moved to rcx to conform to C ABI)
 * r8   arg4
 * r9   arg5
 * (note: r12-r15, rbp, rbx are callee-preserved in C ABI)
 *
 * Only called from user space.
 *
 * When user can change pt_regs->foo always force IRET. That is because
 * it deals with uncanonical addresses better. SYSRET has trouble
 * with them due to bugs in both AMD and Intel CPUs.
 */

    et de 32 bits à arch/x86/entrée/entry_32.S:

    /*
 * 32-bit SYSENTER entry.
 *
 * 32-bit system calls through the vDSO's __kernel_vsyscall enter here
 * if X86_FEATURE_SEP is available.  This is the preferred system call
 * entry on 32-bit systems.
 *
 * The SYSENTER instruction, in principle, should *only* occur in the
 * vDSO.  In practice, a small number of Android devices were shipped
 * with a copy of Bionic that inlined a SYSENTER instruction.  This
 * never happened in any of Google's Bionic versions -- it only happened
 * in a narrow range of Intel-provided versions.
 *
 * SYSENTER loads SS, ESP, CS, and EIP from previously programmed MSRs.
 * IF and VM in RFLAGS are cleared (IOW: interrupts are off).
 * SYSENTER does not save anything on the stack,
 * and does not save old EIP (!!!), ESP, or EFLAGS.
 *
 * To avoid losing track of EFLAGS.VM (and thus potentially corrupting
 * user and/or vm86 state), we explicitly disable the SYSENTER
 * instruction in vm86 mode by reprogramming the MSRs.
 *
 * Arguments:
 * eax  system call number
 * ebx  arg1
 * ecx  arg2
 * edx  arg3
 * esi  arg4
 * edi  arg5
 * ebp  user stack
 * 0(%ebp) arg6
 */

    glibc 2.29 Linux x86_64 appel système de mise en œuvre

    Maintenant, nous allons tricher en regardant l'un des principaux libc implémentations et voir ce qu'ils font.

    Quoi de mieux que de regarder dans la glibc que je suis en ce moment où j'écris cette réponse? 🙂

    glibc 2.29 définit x86_64 appels à sysdeps/unix/sysv/linux/x86_64/sysdep.h et qui contient d'intéressantes code, par exemple:

    /* The Linux/x86-64 kernel expects the system call parameters in
   registers according to the following table:

    syscall number  rax
    arg 1       rdi
    arg 2       rsi
    arg 3       rdx
    arg 4       r10
    arg 5       r8
    arg 6       r9

    The Linux kernel uses and destroys internally these registers:
    return address from
    syscall     rcx
    eflags from syscall r11

    Normal function call, including calls to the system call stub
    functions in the libc, get the first six parameters passed in
    registers and the seventh parameter and later on the stack.  The
    register use is as follows:

     system call number in the DO_CALL macro
     arg 1      rdi
     arg 2      rsi
     arg 3      rdx
     arg 4      rcx
     arg 5      r8
     arg 6      r9

    We have to take care that the stack is aligned to 16 bytes.  When
    called the stack is not aligned since the return address has just
    been pushed.


    Syscalls of more than 6 arguments are not supported.  */

    et:

    /* Registers clobbered by syscall.  */
# define REGISTERS_CLOBBERED_BY_SYSCALL "cc", "r11", "cx"

#undef internal_syscall6
#define internal_syscall6(number, err, arg1, arg2, arg3, arg4, arg5, arg6) \
({                                  \
    unsigned long int resultvar;                    \
    TYPEFY (arg6, __arg6) = ARGIFY (arg6);              \
    TYPEFY (arg5, __arg5) = ARGIFY (arg5);              \
    TYPEFY (arg4, __arg4) = ARGIFY (arg4);              \
    TYPEFY (arg3, __arg3) = ARGIFY (arg3);              \
    TYPEFY (arg2, __arg2) = ARGIFY (arg2);              \
    TYPEFY (arg1, __arg1) = ARGIFY (arg1);              \
    register TYPEFY (arg6, _a6) asm ("r9") = __arg6;            \
    register TYPEFY (arg5, _a5) asm ("r8") = __arg5;            \
    register TYPEFY (arg4, _a4) asm ("r10") = __arg4;           \
    register TYPEFY (arg3, _a3) asm ("rdx") = __arg3;           \
    register TYPEFY (arg2, _a2) asm ("rsi") = __arg2;           \
    register TYPEFY (arg1, _a1) asm ("rdi") = __arg1;           \
    asm volatile (                          \
    "syscall\n\t"                           \
    : "=a" (resultvar)                          \
    : "0" (number), "r" (_a1), "r" (_a2), "r" (_a3), "r" (_a4),     \
      "r" (_a5), "r" (_a6)                      \
    : "memory", REGISTERS_CLOBBERED_BY_SYSCALL);            \
    (long int) resultvar;                       \
})

    qui me semblent assez explicites. Notez comme cela semble avoir été conçu pour correspondre exactement à la convention d'appel de Système régulier de V AMD64 ABI fonctions: https://en.wikipedia.org/wiki/X86_calling_conventions#List_of_x86_calling_conventions

    Rapide rappel de la clobbers:

    • cc signifie drapeau registres. Mais Peter Cordes commentaires que ce n'est pas nécessaire ici.
    • memory signifie qu'un pointeur peut être adoptée en assemblée et utilisée pour accéder à la mémoire

    Explicite minimum praticable exemple à partir de zéro voir cette réponse: Comment appeler un système d'appel à l'aide de sysenter dans un assembly en ligne?

    Faire quelques appels à l'assemblée manuellement

    Pas très scientifique, mais amusant:

    • x86_64.S

      .text
.global _start
_start:
asm_main_after_prologue:
    /* write */
    mov $1, %rax    /* syscall number */
    mov $1, %rdi    /* stdout */
    mov $msg, %rsi  /* buffer */
    mov $len, %rdx  /* len */
    syscall

    /* exit */
    mov $60, %rax   /* syscall number */
    mov $0, %rdi    /* exit status */
    syscall
msg:
    .ascii "hello\n"
len = . - msg

      GitHub en amont.

    Le "cc" clobber est inutile: Linux syscalls sauvegarder/restaurer les RFLAGS (Le syscall/sysret instructions de le faire à l'aide de R11, et le noyau ne doit pas modifier la sauvé R11 / RFLAGS autre que via ptrace débogueur, les appels système.) Non pas que cela jamais de questions, car un "cc" clobber est implicite pour les architectures x86 / x86-64 dans GNU C a Prolongé asm, donc vous ne pouvez pas gagner quoi que ce soit par les laissant.

    OriginalL'auteur Ciro Santilli 新疆改造中心996ICU六四事件