Se você conhece a montagem e como as coisas funcionam no nível OS, você está em conformidade com um certo ABI. A ABI governa coisas como como como os parâmetros são passados, onde os valores de retorno são colocados. Para muitas plataformas há apenas um ABI para escolher, e nesses casos o ABI é apenas "como as coisas funcionam".

No entanto, a ABI também governa coisas como a forma como as classes/objetos são definidos em C++. Isto é necessário se você quiser ser capaz de passar referências de objetos através dos limites do módulo ou se você quer misturar código compilado com compiladores diferentes.

Também, se você tem um SO de 64 bits que pode executar binários de 32 bits, você terá ABIs diferentes para código de 32 - e 64-bits.

Em geral, qualquer código que se ligue ao mesmo executável deve estar em conformidade com o mesmo ABI. Se você quiser se comunicar entre o código usando ABIs diferentes, você deve usar alguma forma de protocolos de RPC ou serialização.

ABIs pode ser (parcialmente) ISA-agnóstico. Alguns aspectos (como chamar convenções) dependem da ISA, enquanto outros aspectos (como layout de Classe C++) não.

Um ABI bem definido é muito importante para as pessoas que escrevem Compiladores. Sem uma ABI bem definida, seria impossível gerar código interoperável.

Editar: algumas notas para clarificar:

• "binário" em ABI não exclui o uso de cadeias de caracteres ou texto. Se você quiser ligar um DLL a exportar uma classe C++, em algum lugar nele os métodos e assinaturas de tipo devem ser codificados. É aí que entra o mutilador de nomes C++.
A razão pela qual você nunca forneceu um ABI é que a grande maioria dos programadores nunca o fará. Os ABIs são fornecidos pelas mesmas pessoas que concebem a plataforma (ou seja, o sistema operativo), e muito poucos programadores terão o privilégio de projetar um ABI amplamente utilizado.

Uma interface binária de Aplicação (ABI) é semelhante a uma API, mas a função não é acessível ao chamador ao nível do código fonte. Apenas uma representação binária é acessível / disponível.

O ABIs pode ser definido ao nível da arquitectura do processador ou ao nível do sistema operacional. Os ABIs são padrões a serem seguidos pela fase gerador de código do compilador. O padrão é fixado pelo SO ou pelo processador.

Funcionalidade: definir o mecanismo / padrão para fazer a função chama independente da linguagem de implementação ou um compilador/linker/toolchain específico. Forneça o mecanismo que permite JNI, ou uma interface Python-C, etc.

Entidades existentes: funções sob a forma de código de máquina.

Consumidor: outra função (incluindo uma Numa outra língua, compilada por outro compilador, ou ligada por outro linker).

Você realmente não precisa de um ABI em tudo se--

O seu programa não tem funções e ...
• o seu programa é um único executável que está a correr sozinho (ou seja, um sistema incorporado) onde é literalmente a única coisa a correr e não precisa de falar com mais nada.

Um resumo simplificado:

API: "Aqui estão todas as funções que você pode chamar."

ABI: "Isto é Como chamar uma função."

A ABI é um conjunto de regras que Compiladores e linkers aderem, a fim de compilar o seu programa para que funcione adequadamente. Os ABIs abrangem vários tópicos:

A maior e mais importante parte de um ABI é, sem dúvida, a chamada padrão de procedimento, por vezes conhecida como "Convenção de chamadas". Chamar convenções padronizar como "funções" são traduzidas para código de montagem. [8]ABIs também dita como o os nomes das funções expostas nas bibliotecas devem ser representados para que outros códigos possam chamar essas bibliotecas e saibam que argumentos devem ser passados. Isto chama-se"mutilação de nomes".
• O ABIs também determina que tipo de dados podem ser utilizados, como devem ser alinhados e outros detalhes de baixo nível.

Olhando mais profundamente para a Convenção de chamadas, que eu considero ser o núcleo de um ABI:

A própria máquina não tem nenhum conceito de "funções". Quando escreves um function in a high-level language like c, the compiler generates a line of assembly code like _MyFunction1:. Este é um label , que eventualmente será resolvido em um endereço pelo montador. Este rótulo marca o" início "da sua" função " no código de montagem. Em código de alto nível, quando você "chama" essa função, o que você está realmente fazendo é fazer com que a CPU para saltar para o endereço dessa etiqueta e continuar executando lá.

Em preparação para o salto, o compilador deve fazer um monte de coisas importantes. A Convenção de chamadas é como uma lista de verificação que o compilador segue para fazer todas estas coisas:

• Primeiro, o compilador introduz um pouco de código de montagem para salvar o endereço atual, de modo que quando a sua "função" é feita, a CPU pode saltar de volta para o lugar certo e continuar a executar.
A seguir, o compilador gera código de montagem para passar os argumentos.
Algumas convenções apelativas ditam que os argumentos devem ser colocados na pilha. ( numa ordem específica claro.
• outras convenções determinam que os argumentos devem ser colocados em registos específicos (dependendo dos seus tipos de dados, é claro).
• ainda há outras convenções que ditam a utilização de uma combinação específica de pilha e registos.
É claro que, se havia algo importante nesses registos antes, esses valores são agora substituídos e perdidos para sempre, por isso algumas convenções chamadoras podem ditar que o compilador deve salvar alguns desses registros antes de colocar os argumentos neles.
• Agora o compilador insere uma instrução de salto dizendo à CPU para ir para a etiqueta que fez anteriormente ({[[0]}). Neste ponto, você pode considerar a CPU como " em " sua "função".
• no final da função, o compilador coloca algum código de montagem que fará com que a CPU escreva o valor de retorno no lugar correto. A Convenção de chamamento vai ditar se o valor de retorno deve ser colocado em um registro particular (dependendo de seu tipo), ou na pilha.
Está na hora da limpeza. A Convenção de chamamento vai ditar onde o compilador coloca o código de montagem de limpeza.
Algumas convenções dizem que quem liga deve limpar a pilha. Isto significa que depois que a "função" é feita e a CPU salta de volta para onde estava antes, o código seguinte a ser executado deve ser algum código de limpeza muito específico. Outras convenções dizem que algumas partes em particular do código de limpeza deve estar no final da" função " antes de {[5] } o salto de volta.

• para a CPU x86 ou x86-64 (ambiente de 32 bits):
  • decl
  • STDCALL
  • FASTCALL
  • VECTORCALL
  • este plano
• para a CPU x86-64 (64 bits) ambiente):
  • SYSTEMV
  • MSNATIVO
  • VECTORCALL
• para a CPU do braço (32 bits)
  • AAPCS
• para a CPU ARM (64 bits)
  • AAPCS64

Aqui está uma grande página que realmente mostra as diferenças na montagem gerada ao compilar para ABIs diferentes.

Outra coisa a mencionar é que um ABI não é apenas relevante {[[4]} dentro do módulo executável do seu programa. É ... Também usado pelo linker para garantir que o seu programa chama a biblioteca correctamente. Você tem várias bibliotecas compartilhadas em execução em seu computador, e desde que o seu compilador sabe o que ABI cada um usa, ele pode chamar funções a partir deles corretamente sem explodir a pilha.

O seu compilador compreender como chamar funções de Biblioteca éextremamente importante . Em uma plataforma hospedada (ou seja, uma onde um sistema operacional carrega programas), seu programa nem sequer pode piscar sem a fazer uma chamada.

Funcionalidade: um conjunto de contratos que afectam o compilador, os escritores de montagem, o linker e o sistema operativo. Os contratos especificam como as funções são estabelecidas, onde os parâmetros são passados, como os parâmetros são passados, como a função retorna funciona. Estes são geralmente específicos de uma tupla (arquitetura de processador, sistema operacional).

Entidades existentes: disposição dos parâmetros, semântica das funções, atribuição dos registos. Por exemplo, as arquiteturas ARM tem inúmeros ABIs (APCS), EABI, GNU-EABI, não importa um monte de casos históricos) - usar o a mixed ABI resultará em seu código simplesmente não funcionar ao chamar através de fronteiras.

O codificador de nomes C++ é um caso especial - é um problema centrado no linker e dinâmico-se o codificador de nomes não for padronizado, então a ligação dinâmica não funcionará. A partir de Agora, o C++ ABI é chamado apenas isso, o C++ ABI. Não é uma questão de nível linker, mas sim uma questão de geração de código. Uma vez que tenha uma binária C++, não é possível torná-la compatível com outra ABI C++ (codificação de nomes, tratamento de exceções) sem recompilar a partir do Código.

O ELF é um formato de ficheiro para o uso de um carregador e linker dinâmico. ELF é um formato de contêiner para código binário e dados, e como tal especifica o ABI de um pedaço de código. Eu não consideraria o ELF um ABI no sentido estrito, já que os executáveis de PE não são um ABI.

Todos os ABIs são específicos do conjunto de instruções. Um ARM ABI não fará sentido em um processador MSP430 ou x86_64.

O Windows tem vários ABIs - por exemplo, fastcall e stdcall são dois ABIs de uso comum. O syscall ABI está diferente outra vez.

A systemcall é uma forma de um programa userspace pedir algo ao kernelspace. Ele funciona colocando o código numérico para a chamada e o argumento em um determinado registro e desencadeando uma interrupção. Do que uma mudança ocorre no kernelspace e o kernel olha para cima o código numérico e o argumento, lida com a solicitação, coloca o resultado de volta num registo e acciona um interruptor de volta para o espaço do utilizador. Isto é necessário, por exemplo, quando a aplicação quer alocar memória ou abrir um arquivo (syscalls "brk" e "open").

Agora os syscalls têm nomes curtos "brk", etc. e opcodes correspondentes, estes são definidos em um arquivo de cabeçalho específico do sistema. Desde que estes opcodes permaneçam os mesmos, você pode executar os mesmos programas de userland compilados com diferentes kernels atualizados sem ter que recompilar. Então você tem uma interface usada por binarys pré-compilados, daí ABI.

A melhor maneira de diferenciar a ABI da API é saber porquê e para que é utilizada:

Para x86-64 existe geralmente um ABI (e para x86 32 bits existe outro set):

Http://www.x86-64.org/documentation/abi.pdf

Https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/LowLevelABI/140-x86-64_Function_Calling_Conventions/x86_64.html

Http://people.freebsd.org/~Brien / amd64-elf-abi.pdf

Linux + FreeBSD + MacOSX seguem - no com algumas ligeiras variações. E o Windows x64 tem o seu próprio ABI:

Http://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64/

Conhecendo a ABI e assumindo que outro compilador também a segue, então os binários teoricamente sabem como chamar uns aos outros (API de bibliotecas em particular) e passar parâmetros sobre a pilha ou por registradores, etc. Ou que registos serão alterados ao chamar as funções etc. Essencialmente, estes conhecimentos ajudarão o software a integrar-se entre si. Conhecer a ordem do registradores / layout de pilha eu posso facilmente montar diferentes softwares escritos em conjuntos juntos, sem muito problema.

Mas a API é diferente:

É um nome de funções de alto nível, com argumento definido, tal que se diferentes peças de software constroem usando esta API, podem ser capazes de chamar uns aos outros. Mas um requisito adicional da mesma ABI deve ser cumprido.

Por exemplo, O Windows costumava ser a API POSIX conforme:

Https://en.wikipedia.org/wiki/Windows_Services_for_UNIX

Https://en.wikipedia.org/wiki/POSIX

E o Linux também é compatível com o POSIX. Mas os binários não podem ser movidos e executados imediatamente. Mas como eles usaram os mesmos nomes na API compatível com POSIX, você pode pegar o mesmo software em C, recompilá-lo nos diferentes SO, e imediatamente colocá-lo em execução.

API são destinados a facilitar integração de software-fase de pré-compilação. Então, após a compilação o software pode parecer totalmente diferente - se o ABI são diferentes.

ABI são destinados a definir a integração exata do software no nível binário / conjunto.

Para chamar código em bibliotecas compartilhadas, ou código de chamada entre unidades de compilação, o arquivo objeto precisa conter etiquetas para as chamadas. O C++ mangles the names of method labels in order to force data hiding and allow for overloaded methods. É por isso que você não pode misturar arquivos de diferentes compiladores C++ a menos que eles explicitamente suportam o mesmo ABI.

Resumo

Existem várias interpretações e opiniões fortes da camada exata que definem um ABI (interface binária de Aplicação).

Na minha opinião, uma ABI é uma convenção subjectiva do que é considerado uma dada/plataforma para uma API específica. A ABI é o" resto "de convenções que" não mudarão " para uma API específica ou que serão abordadas pelo ambiente de execução: executores, ferramentas, linkers, Compiladores, jvm e OS.

Se quiser usar uma biblioteca como a joda-time, deve declarar uma dependência de {[[0]}. A biblioteca segue as melhores práticas e utiliza versionamento semântico . Isto define a compatibilidade da API em três níveis:

Patch-não precisa de alterar o seu código. A biblioteca só arranja alguns insectos. Menor-Você não precisa mudar seu código desde as adições
1. Major-a interface (API) foi alterada e você talvez precises de mudar o teu código.

Para que você possa usar um novo lançamento importante da mesma biblioteca, muitas outras convenções ainda devem ser respeitadas:

• a linguagem binária usada para as bibliotecas (nos casos Java, a versão alvo JVM que define o bytecode Java)
A chamar as convenções.
• convenções JVM
• ligação das convenções
Convenções de tempo de execução Todos estes são definidos e geridos pelas ferramentas que usar.

Exemplos

Estudo de caso Java

Por exemplo, Java padronizou todas estas convenções, não em uma ferramenta, mas em uma especificação JVM formal. A especificação permitiu que outros fornecedores fornecessem um conjunto diferente de ferramentas que podem produzir bibliotecas compatíveis.

Java fornece dois outros estudos de caso interessantes para ABI: versões Scala e dalvik máquina virtual.

O VM Dalvik necessita de um tipo diferente de bytecode do que o bytecode Java. As bibliotecas Dalvik são obtidas convertendo o bytecode Java (com a mesma API) para Dalvik. Desta forma, você pode obter duas versões da mesma API: definida pelo joda-time-1.7.2.jar original. Podíamos chamar-me de joda-time-1.7.2.jar e joda-time-1.7.2-dalvik.jar. Eles usam um ABI diferente para o padrão Java VMs de stack-oriented: Oracle's one, IBM one, open Java ou qualquer outro; e o segundo ABI é o em torno de Dalvik.

Scala as sucessivas versões são incompatível

Scala não tem compatibilidade binária entre versões Scala menores: 2.X. Por esta razão, a mesma API " io.reativex "% % "rxscala" % "0.26.5" tem três versões (no futuro mais): para Scala 2.10, 2.11 e 2.12. O que mudou? Não sei por enquanto, mas os binários não são compatíveis. Provavelmente as versões mais recentes adicionam coisas que tornam as bibliotecas inutilizáveis nas máquinas virtuais antigas, provavelmente coisas relacionadas com linking / naming / parameter convencao.

As versões sucessivas de Java são incompatíveis

Java também tem problemas com os principais lançamentos da JVM: 4,5,6,7,8,9. Eles oferecem apenas compatibilidade reversa. O Jvm9 sabe como executar código compilado / alvo (opção javac -target) para todas as outras versões, enquanto o JVM 4 não sabe como executar código alvo para o JVM 5. Tudo isto enquanto tens uma biblioteca joda. Esta incompatibilidade voa abaixo do radar graças a diferentes soluções:

Semântica versioning: quando as bibliotecas têm como alvo JVM superior, elas geralmente mudam a versão principal.
1. usa o JVM 4 como ABI, e estás segura.
2. o Java 9 adiciona uma especificação sobre como pode incluir o bytecode para o JVM específico na mesma biblioteca.

API e ABI são apenas convenções sobre como se define compatibilidade. As camadas inferiores são genéricas em relação a uma infinidade de semântica de alto nível. É por isso que é fácil faz algumas convenções. O primeiro tipo de convenções é sobre alinhamento de memória, codificação de bytes, chamadas de Convenções, grandes e pequenas codificações endianas, etc. Em cima deles você obtém as convenções executáveis como as outras descritas, vinculando convenções, código de byte intermediário Como o usado por Java ou LLVM IR usado pelo GCC. Em terceiro lugar, você obtém convenções sobre como encontrar bibliotecas, como carregá-las (veja java classloaders). À medida que você vai mais e mais alto em conceitos, você tem novas convenções que considera como um dado adquirido. Por isso não chegaram à versão semântica. Estão implícitas ou colapsadas na versão maior. Poderíamos alterar a versionação semântica com <major>-<minor>-<patch>-<platform/ABI>. Isto é o que está realmente acontecendo já: plataforma já é um rpm, dll, jar (JVM bytecode), war (JVM+servidor web), apk, 2.11 (versão Scala específica) e assim por diante. Quando você diz APK você já fala sobre uma parte específica ABI de sua API.

A API pode ser portada para diferente ABI

O Nível Superior de uma abstração (as fontes escritas contra a API mais alta podem ser recompiladas/portadas para qualquer outra abstração de nível inferior.

APIs portadas em todas as línguas

Existem APIs que são portadas em várias línguas comofluxos reactivos . Em geral, definem mapeamentos para linguagens/plataformas específicas. Eu argumentaria que a API é a especificação mestre formalmente definida na linguagem humana ou mesmo uma linguagem de programação específica. Todos os outros "mappings" são ABI em um sentido, mais API do que o habitual. O mesmo está acontecendo com as demais interfaces.

De uma perspectiva muito simples, podemos tentar compreender a ABI considerando a compatibilidade binária.

O wiki do KDE define uma biblioteca como binária compatível " Se um programa ligado dinamicamente a uma versão anterior da biblioteca continuar a correr com versões mais recentes da biblioteca sem a necessidade de recompilar."Para mais informações sobre a ligação dinâmica, ver ligação estática vs dinâmica ligação

Agora, vamos tentar olhar apenas para os aspectos mais básicos necessários para que uma biblioteca seja compatibilidade binária (assumindo que não há alterações de código fonte na Biblioteca):

1. a mesma / backward compatible instruction set architecture (processor instructions, register file structure, stack organization, memory access types, along with sizes, layout, and alignment of basic data types the processor can directly access)
As mesmas convenções de apelação.
2. o mesmo Convenção de mangling de nomes (isto pode ser necessário se um programa Fortran precisar chamar alguma função de biblioteca C++).

Funcionalidade ABI: compatibilidade binária

Entidades existentes: programa existente / bibliotecas / OS

Consumidor: bibliotecas, OS

Interface binária de Aplicação (ABI)

Funcionalidade:

Tradução do modelo do programador para os dados de domínio do sistema subjacente Tipo, tamanho, alinhamento, a Convenção de chamamento, que controla como os argumentos das funções são passados e os valores de retorno recuperados; números de chamadas do sistema e como um aplicativo deve fazer chamadas do sistema para o sistema operativo; o nome dos compiladores de línguas de alto nível esquema de mutilação, propagação de exceções e chamamento convencao entre compiladores na mesma plataforma, mas não exigem compatibilidade entre plataformas...

Entidades Existentes:

Blocos lógicos que participam directamente na execução do programa: ALU, registos de finalidade geral, registos para mapeamento de memória/ I/O de E / S, etc...

Consumidores:

Processadores de linguagem linker, montador...

Codificação de nomes em C++ porque os ficheiros de objectos de diferentes linguagens de alto nível podem ser necessários para serem ligados na sua aplicação. Considere o uso de biblioteca padrão GCC fazendo chamadas de Sistema Para Windows construídos com C++Visual.

Elfo é uma possível expectativa do linker a partir de um arquivo objeto para interpretação, embora a JVM possa ter alguma outra ideia.

Para uma aplicação do Windows RT Store, tente procurar o ARM ABI se quiser mesmo fazer com que a cadeia de ferramentas do build funcione em conjunto.

O termo ABI é usado para se referir a dois conceitos distintos mas relacionados.

Ao falar de compiladores, refere-se às regras usadas para traduzir de construções de nível fonte para construções Binárias. De que tamanho são os tipos de dados? como funciona a pilha? como passo parâmetros para funções? que registos devem ser salvos pelo chamador contra o callee?

Quando se fala de bibliotecas, refere-se à interface binária apresentada por uma biblioteca compilada. Esta interface é a resultado de uma série de fatores, incluindo o código fonte da biblioteca, as regras usadas pelo compilador e, em alguns casos, as definições pegou de outras bibliotecas.

void initfoo(FOO * foo)
int usefoo(FOO * foo, int bar)
void cleanupfoo(FOO * foo)

E o programador de aplicações escreve código como

int dostuffwithfoo(int bar) {
  FOO foo;
  initfoo(&foo);
  int result = usefoo(&foo,bar)
  cleanupfoo(&foo);
  return result;
}

O programador da aplicação não se importa com o tamanho ou layout do FOO, mas o binário da aplicação termina com um tamanho duro de foo. Se o programador da biblioteca adicionar um campo extra para o foo e alguém usar o binário da nova biblioteca com o binário da aplicação antiga, então a biblioteca pode fazer fora dos limites acessos de memória.

OTOH se o autor da biblioteca tivesse desenhado a sua API como.

FOO * newfoo(void)
int usefoo(FOO * foo, int bar)
void deletefoo((FOO * foo, int bar))

E o programador de aplicações escreve código como

int dostuffwithfoo(int bar) {
  FOO * foo;
  foo = newfoo();
  int result = usefoo(&foo,bar)
  deletefoo(&foo);
  return result;
}

Então o binário da aplicação não precisa saber nada sobre a estrutura do FOO, que pode estar tudo escondido dentro da biblioteca. Preco você paga por isso, no entanto, é que heap operações estão envolvidas.