Entendendo a interface binária do aplicativo (ABI) [closed]

5

Estou tentando entender o conceito da interface binária do aplicativo (ABI).

De O iniciador do kernel do Linux :

An ABI is a set of conventions that allows a linker to combine separately compiled modules into one unit without recompilation, such as calling conventions, machine interface, and operating-system interface. Among other things, an ABI defines the binary interface between these units. ... The benefits of conforming to an ABI are that it allows linking object files compiled by different compilers.

Em Wikipédia :

an application binary interface (ABI) describes the low-level interface between an application (or any type of) program and the operating system or another application.

ABIs cover details such as data type, size, and alignment; the calling convention, which controls how functions' arguments are passed and return values retrieved; the system call numbers and how an application should make system calls to the operating system; and in the case of a complete operating system ABI, the binary format of object files, program libraries and so on.

  1. Eu queria saber se a ABI depende do conjunto de instruções e o sistema operacional. São os dois todos de que a ABI depende?
  2. Quais tipos de papel a ABI desempenha em diferentes estágios de compilação: pré-processamento, conversão de código de C para Assembly, conversão de código do código Assembly to Machine, e ligando?

    A partir da primeira citação acima, parece-me que a ABI é necessária para apenas ligando palco, não os outros estágios. Está correto?

  3. Quando a ABI precisa ser considerada?

    A ABI precisa ser considerada durante a programação em C, Montagem ou outras linguagens? Se sim, como a ABI e a API são diferentes?

    Ou é apenas para vinculador ou compilador?

  4. O ABI é especificado para / no código de máquina, linguagem Assembly, e / ou de C?
por Tim 01.08.2011 / 04:46
fonte

1 resposta

4

A resposta do Kernel do Linux Primer é provavelmente adaptada ao Kernel do Linux. A resposta da Wikipedia é provavelmente mais geral.

No primeiro ponto, você pode dizer com certeza que a ABI depende da plataforma. O que "plataforma" significa pode variar - pode significar hardware físico, pode significar algum tipo de máquina virtual, etc. A ABI pode depender de um grau variável na linguagem e no compilador - que depende da plataforma. Se a ABI é parcialmente definida pelo O / S depende de quão perto a plataforma e o O / S são.

Como a ABI está substancialmente implícita em como o montador (ou outro código) gerado opera, a geração de código (tradução de C ou o que quer que seja para o assembler) deve estar ciente da ABI. Por exemplo, o layout do quadro da pilha para uma chamada de função - particularmente o layout dos parâmetros - é implementado pelas instruções do montador que reservam o espaço necessário e copiam os valores dos parâmetros nesse espaço.

Ao codificar em uma linguagem de alto nível, é muito raro precisar conhecer a ABI em qualquer detalhe, mas é às vezes necessário especificar algumas opções relacionadas à ABI. Um exemplo, em C ++ e direcionado a um PC com Windows, é o uso de sinalizadores de convenção de chamada, como pascal , stdcall e fastcall . Geralmente são necessários ao vincular-se ao código escrito em outro idioma ou ao usar outro compilador (geralmente serviços do sistema operacional), para garantir que o chamador ABI corresponda ao ABI de chamada. Mais raramente, estes podem ser especificados por razões de otimização, como, e. algumas convenções de chamadas podem ser mais eficientes do que outras em circunstâncias particulares.

Se você estiver codificando em assembler e vinculando a sistemas operacionais ou a código escrito em outro idioma, precisará usar as ABIs corretas para esses componentes externos. No entanto, dentro do seu próprio módulo assembler, você está livre para fazer o que quiser - na verdade, inventar sua própria ABI, dependendo apenas das limitações da máquina real ou virtual.

Os compiladores também podem criar suas próprias "convenções de chamada personalizadas", onde eles sabem que uma função só pode ser chamada dentro do mesmo módulo (arquivo de objeto) onde é definida. Isso geralmente é feito por motivos de otimização. Por exemplo, pode ser possível evitar salvar registros que não serão usados dentro dessa função. De um modo limitado, portanto, os compiladores podem improvisar uma ABI.

No entanto, isso é provavelmente um abuso do termo "ABI" - essas "interfaces" improvisadas, por definição, não estão na interface de nenhum módulo.

Existem várias convenções padrão para várias plataformas. Às vezes, elas são estritamente obrigatórias pela própria plataforma - por exemplo, as ABIs usadas para as máquinas virtuais Java e .NET. Em outros casos, as ABIs padrão de fato são definidas por um compilador popular em particular.

Eu imagino que o estado das ABIs na plataforma Windows PC é o mais complexo, devido à longa história com compiladores concorrentes para diferentes idiomas, e com pelo menos 32 bits do Windows ainda suportando programas antigos do MS-DOS. Mas existem sistemas operacionais muito mais antigos, é claro, que foram usados em plataformas de hardware muito mais variadas - sendo o Unix um caso óbvio -, então eu poderia facilmente estar errado sobre isso.

    
por 01.08.2011 / 05:26
fonte