什么是应用程序二进制接口（ABI）？ [英] What is Application Binary Interface (ABI)?

问题描述

我从来没有清楚地了解什么是ABI。我对这样一个冗长的问题，抱歉。我只是想了解清楚的事情。请不要点我的wiki文章，如果能理解的话，我就不会在这里发布这样一个漫长的帖子。

I never clearly understood what is an ABI. I'm sorry for such a lengthy question. I just want to clearly understand things. Please don't point me to wiki article, If could understand it, I wouldn't be here posting such a lengthy post.

这是我对不同接口的心态：

This is my mindset about different interfaces:

电视遥控器是用户和电视机之间的接口。这是现有的实体，但没用（不提供任何功能）本身。所有的每个遥控器上的这些按钮的功能是在电视集合实现。

TV remote is an interface between user and TV. It is an existing entity but useless (doesn't provide any functionality) by itself. All the functionality for each of those buttons on the remote is implemented in the Television set.

接口：这是一个现有实体之间层
  功能和消费者的那
  功能。一，接口本身
  就是什么都不做。它只是
  调用躺在功能
  后面。

Interface: It is a "existing entity" layer between the functionality and consumer of that functionality. An, interface by itself is doesn't do anything. It just invokes the functionality lying behind.

现在取决于用户是有谁
  不同类型的接口。

Now depending on who the user is there are different type of interfaces.

命令行界面（CLI）命令是现有的实体，
  消费者是用户和功能
  的背后。

Command Line Interface(CLI) commands are the existing entities, consumer is the user and functionality lies behind.

功能：我的软件
  功能，这解决了一些
  用途时，我们所描述
  这个接口。

functionality: my software functionality which solves some purpose to which we are describing this interface.

现有的实体：命令

消费者：用户

图形用户界面（GUI）窗口，按钮等。在现有的
  实体，再次消费者是用户
  和功能的背后。

Graphical User Interface(GUI) window,buttons etc.. are the existing entities, again consumer is the user and functionality lies behind.

功能：我的软件
  功能，这解决了一些
  用途时，我们所描述
  这个接口。

functionality: my software functionality which solves some purpose to which we are describing this interface.

现有的实体：窗口，按钮
  等等。

existing entities: window,buttons etc..

消费者：用户

应用程序编程接口（API）的功能还是要
  更正确，接口（以
  基于接口编程）是
  现有的实体，消费者在这里
  另一个程序不是用户。然后再次
  功能位于此层后面。

Application Programming Interface(API) functions or to be more correct, interfaces (in interfaced based programming) are the existing entities, consumer here is another program not a user. and again functionality lies behind this layer.

功能：我的软件
  功能，这解决了一些
  用途时，我们所描述
  这个接口。

functionality: my software functionality which solves some purpose to which we are describing this interface.

现有的实体：的功能，
  接口（函数数组）。

existing entities: functions, Interfaces(array of functions).

消费者：另一
  程序/应用程序。

consumer: another program/application.

应用程序二进制接口（ABI）这里是我的问题开始。

Application Binary Interface (ABI) Here is my problem starts.

功能： ???

现有的实体： ???

消费者： ???

• 我已经写在不同的语言一些软件，并提供不同类型的接口（CLI，GUI，API），但我不知道，如果我，提供的ABI。

维基说：

ABI的支付细节，如

ABIs cover details such as

  
• 的数据类型，大小和排列;

  
• 调用约定，控制功能的论点是如何
    传递和返回值检索;

  
• 系统调用号和一个应用程序应该如何使用系统调用
    到操作系统;

  

其他的ABI标准化细节，如

Other ABIs standardize details such as

  
• C ++的名字改编，[2]。

  
• 异常传播，[3]

  
• 调用编译器之间约定在同一平台上，但这样做
    不要求跨平台
    兼容性。

  

• 谁需要这些细节？请不要说，OS。我知道汇编编程。我知道如何连接和放大器;装载工作。我知道到底发生了什么里面。

• Who needs these details? Please don't say, OS. I know assembly programming. I know how linking & loading works. I know what exactly happens inside.

  在哪里C ++名称重整进来的？我想我们是在二进制级别说话。没有语言从哪里来之间？

  Where did C++ name mangling come in between? I thought we are talking at the binary level. Where did languages come in between?

  反正我已经下载了 [PDF] System V应用程序二进制接口的版4.1（1997- 03-18）的清楚地看到它所包含的内容。嗯，大部分的它没有任何意义。

  anyway, I've downloaded the [PDF] System V Application Binary Interface Edition 4.1 (1997-03-18) to see what exactly it contains. Well, most of it didn't make any sense.

  
  

  • 为什么它含有2章（第4＆安培; 5），它描述了 ELF文件 format.Infact ，这些都是只有2显著章的规范。所有章节处理器的具体休息。无论如何，我认为这是完全不同的主题。请不要说ELF文件格式规范的是的ABI中。它没有资格成为接口根据定义。

  • Why does it contain 2 chapters (4th & 5th) which describe the ELF file format.Infact, these are the only 2 significant chapters that specification. Rest of all the chapters "Processor Specific". Anyway, I thought that it is completely different topic. Please don't say that ELF file format specs are the ABI. It doesn't qualify to be Interface according to the definition.

  我知道，因为我们在如此低的水平谈论它必须是非常具体的。但我不知道是怎么回事指令集架构（ISA）具体点吗？

  I know, since we are talking at such low level it must be very specific. But I'm not sure how is it "Instruction Set Architecture(ISA)" specific?

  在哪里可以找到MS窗口的ABI？

  Where can I find MS Window's ABI?

  那么，这些是被缠着我的主要查询。

  So, these are the major queries that are bugging me.

  推荐答案

  一个简单的方法来理解ABI是比较它API

  One easy way to understand "ABI" is to compare it to "API".

  您已经熟悉的API的概念。如果你想使用的，比方说在功能，一些库或操作系统，你会使用一个API。 API包含数据类型/结构，常量，函数等等，你可以在你的code用来访问外部组件的功能。

  You are already familiar with the concept of an API. If you want to use the features of, say, some library or your OS, you will use an API. The API consists of data types/structures, constants, functions, etc that you can use in your code to access the functionality of that external component.

  这是ABI很相似。把它看成是一个API（或在机器语言级的API）的编译版本。当你写源$ C ​​$ C，你进入图书馆，虽然一个API。一旦code编译，你的应用程序访问中通过ABI库中的二进制数据。该ABI定义了编译的应用程序将使用来访问外部库（就像API一样），只在一个较低的水平的结构和方法。

  An ABI is very similar. Think of it as the compiled version of an API (or as an API on the machine-language level). When you write source code, you access the library though an API. Once the code is compiled, your application accesses the binary data in the library through the ABI. The ABI defines the structures and methods that your compiled application will use to access the external library (just like the API did), only on a lower level.

  ABI的是很重要的，当涉及到使用外部库的应用程序。如果程序是建立在使用特定的库，该库在以后更新，你不希望有重新编译该应用程序（从最终用户的角度来看，你可能没有源）。如果更新库使用相同的ABI，那么你的程序将不需要修改。图书馆的接口（这是所有程序真正关心的）是一样的，即使内部工作可能已经改变。库的两个版本具有相同ABI有时被称为二进制兼容，因为它们具有相同的低层接口（你应该能够用新的替换旧版本，不会有什么大问题）。

  ABIs are important when it comes to applications that use external libraries. If a program is built to use a particular library and that library is later updated, you don't want to have to re-compile that application (and from the end-user's standpoint, you may not have the source). If the updated library uses the same ABI, then your program will not need to change. The interface to the library (which is all your program really cares about) is the same even though the internal workings may have changed. Two versions of a library that have the same ABI are sometimes called "binary-compatible" since they have the same low-level interface (you should be able to replace the old version with the new one and not have any major problems).

  有时，ABI的变化是不可避免的。发生这种情况时，使用该库的任何程序将无法工作，除非他们正在重新编译使用该库的新版本。如果ABI的变化，但API不会，那么新旧库版本有时被称为源兼容。这意味着，当编译一个库版本的程序不会与一个写的其他来源$ C ​​$ C的工作将为其他工作，如果重新编译。

  Sometimes, ABI changes are unavoidable. When this happens, any programs that use that library will not work unless they are re-compiled to use the new version of the library. If the ABI changes but the API does not, then the old and new library versions are sometimes called "source compatible". This implies that while a program compiled for one library version will not work with the other, source code written for one will work for the other if re-compiled.

  由于这个原因，库作家往往会尽量保持自己的稳定的ABI（影响减至最低）。保持在ABI稳定装置不改变功能的接口（返程类型和数量，类型和参数顺序），新功能和数据类型可以加入的数据类型或数据结构，定义常量等的定义，但现有的必须留一样。如果展开，比方说，一个16位的数据结构字段为32位字段，那么已编译code使用该数据结构将无法正确访问该字段（或任何以下的话）。存取数据结构成员编译期间被转换成存储器地址和偏移量，并且如果该数据结构的变化，那么这些偏移不会指向什么code为期望它们指向，结果充其量是未predictable

  For this reason, library writers tend to try to keep their ABI stable (to minimize disruption). Keeping an ABI stable means not changing function interfaces (return type and number, types, and order of arguments), definitions of data types or data structures, defined constants, etc. New functions and data types can be added, but existing ones must stay the same. If you expand, say, a 16-bit data structure field into a 32-bit field, then already-compiled code that uses that data structure will not be accessing that field (or any following it) correctly. Accessing data structure members gets converted into memory addresses and offsets during compilation and if the data structure changes, then these offsets will not point to what the code is expecting them to point to and the results are unpredictable at best.

  这是ABI未必是你将明确规定，除非你期望的人与你的code使用汇编接口。它不是特定于语言的，因为相关（比如）一个C应用程序和应用程序的Pascal将使用相同​​的ABI被编译之后。

  An ABI isn't necessarily something you will explicitly provide unless you are expecting people to interface with your code using assembly. It isn't language-specific either, since (for example) a C application and a Pascal application will use the same ABI after they are compiled.

  编辑：关于你提到的关于关于在SysV的ABI文档ELF文件格式的章节问题：包含此信息的原因是因为ELF格式定义的操作系统和应用程序之间的接口。当你告诉操作系统运行一个程序，它希望以某种方式进行格式化程序，（例如）预计的二进制文件的第一部分是包含特定的内存偏移某些信息的ELF头。这是怎样的应用程序通信有关本身对操作系统的重要信息。如果在非ELF二进制格式（如out或PE），然后是操作系统，预计ELF格式的应用程序将无法跨preT二进制文件或运行应用程序建立一个程序。这是一个很大的原因的Windows应用程序不能直接在Linux机器（反之亦然）而不被要么重新编译或某些类型的模拟层内运行，可以从一个二进制格式转换为另一种运行。

  Regarding your question about the chapters regarding the ELF file format in the SysV ABI docs: The reason this information is included is because the ELF format defines the interface between operating system and application. When you tell the OS to run a program, it expects the program to be formatted in a certain way and (for example) expects the first section of the binary to be an ELF header containing certain information at specific memory offsets. This is how the application communicates important information about itself to the operating system. If you build a program in a non-ELF binary format (such as a.out or PE), then an OS that expects ELF-formatted applications will not be able to interpret the binary file or run the application. This is one big reason why Windows apps cannot be run directly on a Linux machine (or vice versa) without being either re-compiled or run inside some type of emulation layer that can translate from one binary format to another.

  IIRC，目前的Windows上使用移植可执行（或PE）格式。有迹象表明，维基百科页面的外部链接部分中的链接与关于PE格式的更多信息。

  IIRC, Windows currently uses the Portable Executable (or, PE) format. There are links in the "external links" section of that Wikipedia page with more information about the PE format.

  此外，关于你对C ++的名字改编注：ABI可以为一个C定义标准化的方式++编译器做的名字改编的兼容性的目的。也就是说，如果我创建了一个库，开发使用该库的程序，你应该能够使用不同的编译器比我根本不担心生成的二进制代码是不兼容的，由于不同名称重整方案。这的确是唯一使用的，如果你要定义一个新的二进制文件格式或编写一个编译器或链接。

  Also, regarding your note about C++ name mangling: The ABI can define a "standardized" way for a C++ compiler to do name mangling for the purpose of compatibility. That is, if I create a library and you develop a program that uses the library, you should be able to use a different compiler than I did and not have to worry about the resulting binaries being incompatible due to different name mangling schemes. This is really only of use if you are defining a new binary file format or writing a compiler or linker.

  这篇关于什么是应用程序二进制接口（ABI）？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！