Différence entre API et ABI

Question

Je suis novice en matière de programmation de systèmes Linux et j'ai rencontré les notions d'API et d'ABI au cours de mes lectures. Programmation du système Linux .

Définition de l'API :

Une API définit les interfaces par lesquelles une pièce de logiciel communique avec un autre au niveau de la source.

Définition de l'ABI :

Alors qu'une API définit une source une interface source, une ABI définit l'interface binaire de bas niveau entre deux ou plus de logiciels sur une architecture particulière. Elle définit comment une application interagit avec elle-même, comment une application interagit avec le noyau, et comment une l'application interagit avec les bibliothèques.

Comment un programme peut-il communiquer au niveau de la source ? Qu'est-ce qu'un niveau source ? Est-il lié au code source d'une manière ou d'une autre ? Ou la source de la bibliothèque est incluse dans le programme principal ?

La seule différence que je connais est que l'API est surtout utilisée par les programmeurs et que l'ABI est surtout utilisée par un compilateur.

Answer 1

( A pplication B inary I nterface) Une spécification pour une plate-forme matérielle spécifique combinée au système d'exploitation. Il s'agit d'une étape au-delà de l'API ( A pplication P rogramme I nterface), qui définit les appels de l'application au système d'exploitation. L'ABI définit l'API ainsi que le langage machine pour une famille de CPU particulière. Une API ne garantit pas la compatibilité d'exécution, mais une ABI le fait, car elle définit le format du langage machine, ou d'exécution.

Avec l'aimable autorisation de

Answer 2

Permettez-moi de donner un exemple précis de la différence entre ABI et API en Java.

Un changement incompatible avec l'ABI est le suivant : si je modifie une méthode A#m() pour qu'elle prenne un fichier String en tant qu'argument pour String... argument. C'est non compatible ABI parce que vous devez recompiler le code qui appelle ça, mais c'est est compatible avec l'API car vous pouvez le résoudre en recompilant sans modifier le code de l'appelant.

Voici l'exemple en détail. J'ai ma bibliothèque Java avec la classe A

// Version 1.0.0
public class A {
    public void m(String string) {
        System.out.println(string);
    }
}

Et j'ai une classe qui utilise cette bibliothèque

public class Main {
    public static void main(String[] args) {
        (new A()).m("string");
    }
}

L'auteur de la bibliothèque a compilé sa classe A, j'ai compilé ma classe Main et tout fonctionne bien. Imaginez qu'une nouvelle version de A arrive

// Version 2.0.0
public class A {
    public void m(String... string) {
        System.out.println(string[0]);
    }
}

Si je prends simplement la nouvelle classe compilée A et que je la dépose avec la classe précédemment compilée Main, j'obtiens une exception en tentant d'invoquer la méthode

Exception in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V
        at Main.main(Main.java:5)

Si je recompile Main, cela est corrigé et tout fonctionne à nouveau.

Answer 3

Votre programme (code source) peut être compilé avec des modules qui fournissent des informations appropriées. API .

Votre programme (binaire) peut être exécuté sur des plates-formes qui fournissent des services appropriés. ABI .

L'API restreint les définitions de type, les définitions de fonction, les macros, parfois les variables globales qu'une bibliothèque doit exposer.

L'ABI restreint ce qu'une "plate-forme" doit fournir pour que votre programme puisse fonctionner. J'aime la considérer à 3 niveaux :

• le niveau du processeur - le jeu d'instructions, la convention d'appel

• au niveau du noyau - la convention d'appel système, la convention spéciale de chemin d'accès aux fichiers (par exemple, le /proc et /sys sous Linux), etc.

• Au niveau du système d'exploitation - le format des objets, les bibliothèques d'exécution, etc.

Considérons un compilateur croisé nommé arm-linux-gnueabi-gcc . "arm" indique l'architecture du processeur, "linux" indique le noyau, "gnu" indique que ses programmes cibles utilisent la libc de GNU comme bibliothèque d'exécution, différente de arm-linux-androideabi-gcc qui utilisent l'implémentation libc d'Android.

Answer 4

API - Application Programming Interface est un compiler interface de temps qui peut être utilisée par développeur d'utiliser des fonctionnalités non liées au projet, comme les appels à la bibliothèque, au système d'exploitation ou au noyau dans le cadre du projet. code source

ABI [À propos] - Application Binary Interface est un temps de fonctionnement interface qui est utilisée par un programme lors de son exécution pour la communication entre les composants de l'entreprise. code machine

Answer 5

L'ABI fait référence à la disposition d'un fichier objet / d'une bibliothèque et d'un binaire final du point de vue de la réussite de la liaison, du chargement et de l'exécution de certains binaires sans que des erreurs de liaison ou des erreurs logiques ne se produisent en raison d'une incompatibilité binaire.

• La spécification du format binaire (PE, COFF, ELF, .obj, .o, .a, .lib (bibliothèque d'importation, bibliothèque statique), .NET assembly, .pyc, COM .dll) : les en-têtes, le format des en-têtes, la définition de l'emplacement des sections et des tables d'importation/exportation/exception et leur format.
• Le jeu d'instructions utilisé pour coder les octets de la section de code, ainsi que les instructions machine spécifiques.
• La signature réelle des fonctions et des données telles que définies dans l'API (ainsi que la façon dont elles sont représentées dans le binaire (les 2 points suivants)).
• La convention d'appel des fonctions de la section de code, qui peuvent être appelées par d'autres binaires (les fonctions qui sont réellement exportées sont particulièrement importantes pour la compatibilité ABI).
• La manière dont les données sont représentées et alignées dans la section des données par rapport à leur type (les données qui sont effectivement exportées sont particulièrement importantes pour la compatibilité ABI).
• Les numéros d'appel système ou les vecteurs d'interruption accrochés dans le code
• La décoration du nom des fonctions et des données exportées
• Directives de linker dans les fichiers objets
• Les drapeaux et directives du préprocesseur, du compilateur, de l'assembleur et de l'éditeur de liens utilisés par le programmeur de l'API et la manière dont ils sont interprétés pour omettre, optimiser, mettre en ligne ou modifier la liaison de certains symboles ou codes dans la bibliothèque ou le binaire final (qu'il s'agisse d'un binaire .dll ou de l'exécutable en cas de liaison statique).

Le format du bytecode de .NET C# est un ABI (général), qui inclut le format .dll de l'assemblage .NET. La machine virtuelle qui interprète le bytecode a une ABI spécifique basée sur C++, où les types doivent être marshallés entre les types natifs C++ que l'ABI spécifique du code natif utilise et les types encadrés de l'ABI de la machine virtuelle lors de l'appel du bytecode depuis le code natif et du code natif depuis le bytecode. J'appelle ici l'ABI d'un programme spécifique une ABI spécifique, alors qu'une ABI en général, telle que "MS ABI" ou "C ABI" fait simplement référence à la convention d'appel et à la manière dont les structures sont organisées, mais pas à une incarnation spécifique de l'ABI par un binaire spécifique qui introduit un nouveau niveau de problèmes de compatibilité ABI.

Une API fait référence à l'ensemble des définitions de type exportées par une bibliothèque particulière importée et utilisée dans une unité de traduction particulière, du point de vue du compilateur d'une unité de traduction, pour résoudre et vérifier avec succès les références de type afin de pouvoir compiler un binaire, et ce binaire adhérera à la norme de l'ABI cible, de sorte que si la bibliothèque qui implémente réellement l'API est également compilée avec une ABI compatible, elle sera liée et fonctionnera comme prévu. Si l'API est mise à jour, l'application peut toujours se compiler, mais il y aura désormais une incompatibilité binaire et il faudra donc utiliser un nouveau binaire.

Une API implique :

• Fonctions, variables, classes, objets, constantes, leurs noms, types et définitions présentés dans le langage dans lequel ils sont codés de manière syntaxiquement et sémantiquement correcte.
• Ce que ces fonctions font réellement et comment les utiliser dans la langue source.
• les fichiers de code source qui doivent être inclus / les binaires qui doivent être liés afin de les utiliser, et la compatibilité ABI de ceux-ci