Qu'est-ce que l'interface binaire d'application (ABI)?

Question

Je n'ai jamais compris clairement ce qui est de l'ABI. Je suis désolé pour ces longs question. Je veux juste bien comprendre les choses. Merci de ne pas me pointer à l'article wiki, Si elle pouvait le comprendre, je ne serais pas ici de poster un aussi long post.

C'est mon état d'esprit sur les différentes interfaces:

Télécommande TV est une interface entre l'utilisateur et de la TÉLÉVISION. C'est une entité existante, mais inutile (ne fournit pas toutes les fonctionnalités) par lui-même. Toutes les fonctionnalités de chacun de ces boutons sur la télécommande est mise en œuvre dans le poste de Télévision.

Interface: C'est une "entité existante" couche entre le functionality et consumer de la fonctionnalité. Une, interface en elle-même est ne rien faire. Il vient de invoque la fonctionnalité de mentir derrière.

Maintenant, en fonction de l'identité de l'utilisateur est-il sont différents type d'interfaces.

Interface de Ligne de commande(CLI) les commandes sont les entités existantes, la consommation est l'utilisateur et la fonctionnalité qui se cache derrière.

functionality: mon logiciel la fonctionnalité qui résout certains but pour lequel nous sommes décrivant cette interface.

existing entities: commandes

consumer: utilisateur

Interface Utilisateur graphique(GUI) de la fenêtre,les boutons, etc.. sont les entités, le nouveau consommateur est l'utilisateur et la fonctionnalité se trouve derrière.

functionality: mon logiciel la fonctionnalité qui résout certains but pour lequel nous sommes décrivant cette interface.

existing entities:de la fenêtre,les boutons etc..

consumer: utilisateur

Interface de Programmation d'Application(API) de fonctions ou à être de plus correct, les interfaces (en interfacé en fonction de la programmation) sont les les entités existantes, la consommation est ici un autre programme et non à un utilisateur. et encore la fonctionnalité se trouve derrière cette couche.

functionality: mon logiciel la fonctionnalité qui résout certains but pour lequel nous sommes décrivant cette interface.

existing entities:fonctions, Interfaces(tableau de fonctions).

consumer:autre programme/de l'application.

Application Binary Interface (ABI) , Voici mon problème commence.

functionality: ???

existing entities: ???

consumer: ???

• J'ai écrit quelques logiciels dans différentes langues différents types d'interfaces (CLI, GUI, API), mais je ne suis pas sûr que, si jamais je, à condition que les ABI.

Wikipédia dit:

ABIs détails de la couverture tels que

• type de données, la taille et l'alignement;
• la convention d'appel, qui contrôle la manière dont les arguments des fonctions sont passé et retourner les valeurs récupérées;
• le système de numéros d'appel et la façon dont l'application devrait faire des appels système pour le système d'exploitation;

D'autres ABIs normaliser les détails tels que

• le C++ name mangling,[2] .
• la propagation d'exception,[3] et
• convention d'appel entre les compilateurs sur la même plate-forme, mais ne pas besoin de la croix-plate-forme la compatibilité.

• Qui a besoin de ces détails? Merci de ne pas dire, OS. Je sais assemblage de programmation. Je sais comment la liaison et des travaux de chargement. Je sais exactement ce qui se passe à l'intérieur.

• Où avez-C++ name mangling venir entre les deux? Je pensais que nous parlons au niveau binaire. Où avez-langues il y a entre les deux?

de toute façon, j'ai téléchargé le [PDF] Système V Application Binary Interface Edition 4.1 (1997-03-18) pour voir exactement ce qu'il contient. Eh bien, elle n'a pas de sens.

• Pourquoi a-t-il contenir 2 chapitres (4 et 5) qui décrivent l' ELFE de format de fichier.En effet, ce sont les 2 seuls chapitres importants de la spécification. Reste de tous les chapitres "Processeur Spécifique". De toute façon, j'ai pensé qu'il est sujet complètement différent. Merci de ne pas dire que l'ELFE format de fichier specs sont l'ABI. Il n'est pas admissible à être Interface selon la définition.

• Je sais, puisque nous parlons à ce bas niveau, il doit être très précis. Mais je ne suis pas sûr de savoir comment est-il "l'Instruction Set Architecture(ISA)" spécifique?

• Où puis-je trouver MME de la Fenêtre ABI?

Donc, ce sont les principales requêtes qui m'énerve.

Answer 1

Une manière facile à comprendre "ABI" est de le comparer à "API".

Vous êtes déjà familier avec le concept d'une API. Si vous souhaitez utiliser les fonctionnalités de, disons, une bibliothèque ou votre système d'exploitation, vous devrez utiliser une API. L'API se compose de types de données/structures, de constantes, de fonctions, etc que vous pouvez utiliser dans votre code pour accéder à la fonctionnalité de ce composant externe.

L'ABI est très similaire. Il pense que la version compilée d'une API (ou de l'API sur la machine-niveau de langue). Lorsque vous écrivez du code source, vous pouvez accéder à la bibliothèque si une API. Une fois que le code est compilé, votre application accède à des données binaires dans la bibliothèque par le biais de l'ABI. L'ABI définit les structures et les méthodes que votre application compilée allez utiliser pour accéder à la bibliothèque externe (comme l'API n'), uniquement sur un niveau inférieur.

ABIs sont importants quand il s'agit d'applications qui utilisent des bibliothèques externes. Si un programme est d'utiliser une bibliothèque particulière, et que la bibliothèque est mis à jour ultérieurement, vous ne voulez pas avoir à re-compiler l'application (et à partir de la fin-de l'utilisateur du point de vue, vous ne pouvez pas avoir la source). Si la mise à jour de la bibliothèque utilise le même ABI, alors votre programme n'aura pas besoin de changer. L'interface de la bibliothèque (qui est votre programme se soucie vraiment de l') est le même, même si le fonctionnement interne peuvent avoir changé. Deux versions d'une bibliothèque qui ont la même ABI sont parfois appelés "compatibilité binaire" car ils ont la même interface de bas niveau (vous devriez être en mesure de remplacer l'ancienne version par la nouvelle et de ne pas avoir de problèmes majeurs).

Parfois, ABI changements sont inévitables. Lorsque cela se produit, tous les programmes qui utilisent la bibliothèque ne fonctionnera pas, sauf si ils sont re-compilé pour utiliser la nouvelle version de la bibliothèque. Si les modifications d'ABI, mais l'API n'est pas, alors les anciennes et les nouvelles versions de la bibliothèque sont parfois appelés "compatible". Cela implique que si un programme compilé pour une version de bibliothèque ne fonctionnera pas avec les autres, le code source écrit pour que l'on va travailler pour les autres si la re-compilation.

Pour cette raison, bibliothèque des écrivains ont tendance à essayer de garder leurs ABI stable (afin de minimiser les perturbations). En gardant un ABI stable signifie pas la fonction de changement d'interface (type de retour et le nombre, les types et l'ordre des arguments), les définitions des types de données ou des structures de données, défini constantes, etc. De nouvelles fonctions et types de données peuvent être ajoutés, mais celles existantes doit rester le même. Si vous développez, disons, une 16-bits de données de champ de structure en 32 bits, alors déjà compilé le code qui utilise cette structure de données ne sera pas accès à ce champ (ou tout) correctement. Accéder à la structure de données des membres est converti en mémoire les adresses et les décalages lors de la compilation, et si la structure de données de mutations, ces décalages ne sera pas le point de ce que le code s'attend à point et les résultats sont imprévisibles.

Un ABI n'est pas forcément quelque chose de vous fournir explicitement sauf si vous vous attendez les gens à l'interface avec votre code à l'aide de l'assemblée. Il n'est pas spécifique à la langue, puisque (par exemple) d'une application C et Pascal application va utiliser le même ABI fois qu'ils sont compilés.

Edit: Concernant votre question sur les chapitres concernant l'ELFE format de fichier dans le SysV ABI docs: La raison pour laquelle cette information est incluse est parce que le format ELF définit l'interface entre le système d'exploitation et l'application. Quand vous dites le système d'exploitation pour exécuter un programme, il s'attend à ce que le programme sera formaté d'une certaine façon (par exemple) s'attend à ce que la première section du binaire à être un ELFE en-tête contenant certaines informations à des décalages de mémoire. C'est la façon dont l'application communique des informations importantes à propos de lui-même pour le système d'exploitation. Si vous créez un programme dans un non-format binaire ELF (comme un.ou PE), un OS qui attend ELF-formaté les demandes ne seront pas en mesure d'interpréter le fichier binaire ou de l'exécution de l'application. C'est une grande raison pourquoi les applications Windows ne peut pas être exécuté directement sur une machine Linux (ou vice versa) sans être re-compiler ou exécuter à l'intérieur d'un certain type de couche d'émulation qui peut traduire à partir d'un format binaire à l'autre.

IIRC, Windows utilise actuellement le fichier Exécutable Portable (ou PE) format. Il y a des liens dans la partie "liens externes" de l'article de Wikipédia page avec plus d'informations sur le format PE.

Aussi, concernant votre remarque sur le C++ name mangling: L'ABI pouvez définir un "normalisé" façon pour un compilateur C++ pour faire amputation des noms pour des raisons de compatibilité. Qui est, si je créer une bibliothèque et d'élaborer un programme qui utilise la bibliothèque, vous devriez être en mesure d'utiliser un autre compilateur que j'ai fait et ne pas avoir à vous soucier de les binaires incompatibles en raison des différentes name mangling régimes. Ce n'est vraiment que de l'utilisation si vous définissez un nouveau format de fichier binaire ou l'écriture d'un compilateur ou l'éditeur de liens.

Answer 2

Si vous connaissez assemblée et comment les choses fonctionnent au niveau de l'OS, vous êtes conformes à un certain ABI. L'ABI régissent des choses comme la façon dont les paramètres sont passés, où les valeurs de retour sont placés. Pour de nombreuses plates-formes il y a un seul ABI à choisir, et dans ces cas, l'ABI est juste "comment les choses fonctionnent".

Cependant, l'ABI régissent aussi des choses comme la façon dont les classes/objets sont disposés en C++. Cela est nécessaire si vous voulez être en mesure de transmettre les références de l'objet à travers le module de limites ou si vous voulez mélanger le code compilé avec différents compilateurs.

Aussi, si vous avez un système d'exploitation 64 bits qui peut exécuter les binaires 32 bits, vous avez différentes ABIs pour 32 et 64 bits de code.

En général, un code vous lien dans le même exécutable doit se conformer à la même ABI. Si vous voulez communiquer entre le code à l'aide de différents ABIs, vous devez utiliser une certaine forme de RPC ou de la sérialisation des protocoles.

Je pense que vous essayez trop dur de se faufiler dans les différents types d'interfaces dans un ensemble fixe de caractéristiques. Par exemple, une interface ne doit pas nécessairement être divisé en les consommateurs et les producteurs. Une interface est juste une convention par laquelle deux entités interagissent.

ABIs peut être (partiellement) ISA-agnostique. Certains aspects (tels que les conventions d'appel) dépendent de l'ISA, tandis que d'autres aspects (comme le C++ de la classe de mise en page) ne le font pas.

Une bien défini ABI est très important pour les gens de l'écriture de compilateurs. Sans un sens bien défini ABI, il serait impossible de produire de la interopérables code.

EDIT: Quelques notes pour préciser:

• "Binaire" ABI n'exclut pas l'utilisation de cordes ou de texte. Si vous souhaitez faire un lien d'une DLL à l'exportation d'une classe C++, quelque part en elle, les méthodes et le type de signatures doivent être encodés. C'est là que C++ nom du modificateur.
• La raison pourquoi vous n'avez jamais fourni de l'ABI est que la grande majorité des programmeurs ne le ferai jamais. ABIs sont fournis par les mêmes personnes de la conception de la plate-forme (c'est à dire de système d'exploitation), et très peu de programmeurs auront jamais le privilège de la conception d'un moyen largement utilisé ABI.

Answer 3

Application Binary Interface (ABI) similaire à l'API, mais la fonction n'est pas accessible à l'appelant au code source. seulement une représentation binaire est accessible et disponible.

ABIs peut être défini au niveau du processeur de l'architecture au niveau ou au niveau de l'OS. l'ABIs sont les normes à respecter par le générateur de code phase du compilateur. le standard est fixé soit par le système d'exploitation ou par le processeur.

fonctionnalité: définir le mécanisme standard pour faire des appels de fonction indépendant de la mise en œuvre de la langue ou d'un compilateur/linker/toolchain. fournir un mécanisme qui permet JNI, ou python-c interface etc

les entités existantes: les fonctions de la machine sous forme de code.

consommateur: une autre fonction (y compris un autre dans une autre langue, compilé par un compilateur, ou lié par un autre éditeur de liens)

Answer 4

Fonctionnalité: Un ensemble de contrats qui affectent le compilateur, de l'assemblée des écrivains, l'éditeur de liens, et le système d'exploitation. Les contrats de spécifier la manière dont les fonctions sont définies, où les paramètres sont passés, comment les paramètres sont transmis, comment la fonction retourne travailler. Ce sont généralement spécifiques à un (architecture de processeur, système d'exploitation) n-uplet.

Les entités existantes: paramètre de mise en page, la fonction de la sémantique, de l'allocation de registres. Par exemple, le BRAS architectures a de nombreux ABIs (APC, EABI, GNU-EABI, jamais l'esprit d'un tas de cas historiques) - à l'aide de l'mixte ABI fera en sorte que votre code ne fonctionne pas lors de l'appel à travers les frontières.

Consommateur: Le compilateur, de l'assemblée des écrivains, système d'exploitation, PROCESSEUR d'architecture spécifiques.

Qui a besoin de ces détails? Le compilateur, de l'assemblée des écrivains, des éditeurs de liens qui ne la génération de code (ou de l'alignement des exigences), le système d'exploitation (gestion des interruptions, syscall interface). Si vous n'avez assemblage de programmation, vous avez été conforme à un ABI!

C++ name mangling est un cas spécial - un éditeur de liens et l'éditeur de liens dynamique centrée question - si le nom d'amputation n'est pas normalisé, puis la liaison dynamique ne fonctionne pas. Désormais, l'ABI C++ est appelé juste que, l'ABI C++. Il n'est pas un linker problème de niveau, mais plutôt de la génération de code en question. Une fois que vous avez un C++ binaire, il n'est pas possible pour le rendre compatible avec un autre ABI C++ (name mangling, la gestion des exceptions) sans avoir à recompiler à partir de la source.

ELF est un format de fichier pour l'utilisation d'un chargeur et de l'éditeur de liens dynamiques. ELF est un format de conteneur pour le code binaire et les données, et en tant que tel spécifie l'ABI d'un morceau de code. Je ne serais pas envisager l'ELFE à l'ABI dans le sens strict, comme des exécutables PE ne sont pas de l'ABI.

Tous les ABIs sont jeu d'instructions spécifiques. Un BRAS ABI ne fera pas de sens sur un MSP430 ou x86_64 processeur.

Windows a plusieurs ABIs - par exemple, fastcall et stdcall sont deux communes de l'utilisation ABIs. Le syscall ABI est encore différent.

Answer 5

Laissez-moi au moins de répondre à une partie de votre question. Avec un exemple de la façon dont l'ABI Linux affecte la systemcalls, et pourquoi c'est utile.

Un systemcall est une façon pour un programme de l'espace utilisateur de demander à la kernelspace pour quelque chose. Il fonctionne en mettant le code numérique de l'appel et de l'argument dans un certain registre et le déclenchement d'une interruption. Que d'un interrupteur se produit à kernelspace et le noyau regarde le code numérique et de l'argument, les poignées de la demande, met le résultat dans un registre et déclenche un interrupteur de retour vers l'espace utilisateur. Ceci est nécessaire par exemple lorsque l'application veut allouer de la mémoire ou d'ouvrir un fichier (syscalls "brk" et "ouvrir").

Maintenant, les appels ont des noms courts "brk", etc. et correspondant opcodes, ceux-ci sont définis dans un système spécifique fichier d'en-tête. Aussi longtemps que ces opcodes rester la même, vous pouvez exécuter le même compilé les programmes utilisateurs avec différents noyaux mis à jour sans avoir à recompiler. Si vous disposez d'une interface utilisée par précompilés binarys, donc ABI.