Interface binária do aplicativo - Application binary interface

Image
Uma comparação de alto nível de APIs e ABIs in-kernel e kernel-to-userspace
Image
O kernel do Linux e a biblioteca GNU C definem a API do Linux . Após a compilação, os binários oferecem uma ABI. Manter essa ABI estável por um longo tempo é importante para os ISVs .

No software de computador , uma interface binária de aplicativo ( ABI ) é uma interface entre dois módulos de programa binários. Freqüentemente, um desses módulos é uma biblioteca ou instalação do sistema operacional e o outro é um programa que está sendo executado por um usuário.

Uma ABI define como as estruturas de dados ou rotinas computacionais são acessadas em código de máquina , que é um formato de baixo nível dependente de hardware. Em contraste, uma API define esse acesso no código-fonte , que é um formato de nível relativamente alto, independente de hardware e geralmente legível . Um aspecto comum de uma ABI é a convenção de chamada , que determina como os dados são fornecidos como entrada ou lidos como saída de rotinas computacionais. Exemplos disso são as convenções de chamada x86 .

A adesão a uma ABI (que pode ou não ser oficialmente padronizada) geralmente é tarefa de um compilador , sistema operacional ou autor de biblioteca. No entanto, um programador de aplicativo pode ter que lidar com uma ABI diretamente ao escrever um programa em uma combinação de linguagens de programação, ou mesmo ao compilar um programa escrito na mesma linguagem com diferentes compiladores.

Descrição

ABIs cobrem detalhes como:

  • um conjunto de instruções do processador (com detalhes como a estrutura do arquivo de registro, organização da pilha, tipos de acesso à memória, ...)
  • os tamanhos, layouts e alinhamentos de tipos de dados básicos que o processador pode acessar diretamente
  • a convenção de chamada , que controla como os argumentos das funções são passados ​​e os valores de retorno recuperados. Por exemplo, ele controla:
    • se todos os parâmetros são passados ​​na pilha ou alguns são passados ​​em registradores;
    • quais registros são usados ​​para quais parâmetros de função;
    • e se o primeiro parâmetro de função passado na pilha é empurrado primeiro ou por último.
  • como um aplicativo deve fazer chamadas do sistema para o sistema operacional e se a ABI especifica chamadas diretas do sistema em vez de chamadas de procedimento para stubs de chamadas do sistema, os números de chamada do sistema.
  • e, no caso de um ABI de sistema operacional completo, o formato binário de arquivos de objetos , bibliotecas de programas e assim por diante.

ABIs completos

Uma ABI completa, como o Intel Binary Compatibility Standard (iBCS), permite que um programa de um sistema operacional compatível com essa ABI seja executado sem modificações em qualquer outro sistema, desde que as bibliotecas compartilhadas necessárias estejam presentes e pré-requisitos semelhantes sejam atendidos.

Outros ABIs padronizam detalhes, como mutilação de nome C ++ , propagação de exceção e convenção de chamada entre compiladores na mesma plataforma, mas não requerem compatibilidade entre plataformas.

ABIs incorporados

Uma interface binária de aplicativo embutido (EABI) especifica convenções padrão para formatos de arquivo , tipos de dados, uso de registro, organização de estrutura de pilha e passagem de parâmetro de função de um programa de software embutido , para uso com um sistema operacional embutido .

Compiladores que suportam o EABI criam código-objeto compatível com o código gerado por outros compiladores, permitindo que os desenvolvedores vinculem bibliotecas geradas com um compilador ao código-objeto gerado com outro compilador. Os desenvolvedores que escrevem seu próprio código de linguagem assembly também podem interagir com o assembly gerado por um compilador compatível.

Os EABIs são projetados para otimizar o desempenho dentro dos recursos limitados de um sistema embarcado. Portanto, os EABIs omitem a maioria das abstrações feitas entre o kernel e o código do usuário em sistemas operacionais complexos. Por exemplo, a vinculação dinâmica pode ser evitada para permitir executáveis ​​menores e carregamento mais rápido, o uso de registro fixo permite pilhas mais compactas e chamadas de kernel, e a execução do aplicativo em modo privilegiado permite acesso direto à operação de hardware personalizado sem o engano de chamar um driver de dispositivo. A escolha do EABI pode afetar o desempenho.

Os EABIs amplamente usados ​​incluem PowerPC , Arm EABI e MIPS EABI. Implementações de software específicas, como a biblioteca C, podem impor limitações adicionais para formar ABIs mais concretas; um exemplo é o GNU OABI e o EABI para ARM, ambos os quais são subconjuntos do ARM EABI.

Veja também

Referências

links externos