Comprensione dell'applicazione interfaccia binaria (ABI) [chiuso]

5

Sto cercando di capire il concetto di Application binary interface (ABI).

Da Linux Kernel Primer :

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.

Da Wikipedia :

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. Mi chiedevo se l'ABI dipenda dal set di istruzioni e il sistema operativo. I due dipendono interamente da ABI?
  2. Che tipo di ruolo gioca ABI nelle diverse fasi della compilazione: preelaborazione, conversione del codice da C a Assembly, conversione di codice da Assemblaggio a Codice macchina e collegamento?

    Dalla prima citazione sopra, mi sembra che l'ABI sia necessario solo fase di collegamento, non le altre fasi. È corretto?

  3. Quando è necessario prendere in considerazione l'ABI?

    L'ABI deve essere considerato durante la programmazione in C, Assemblea o altre lingue? In caso affermativo, in che modo ABI e API sono diversi?

    O è solo per linker o compilatore?

  4. L'ABI è specificato per / nel codice macchina, linguaggio Assembly, e / o di C?
posta Tim 01.08.2011 - 04:46
fonte

1 risposta

4

La risposta di Linux Kernel Primer è probabilmente adattata al kernel di Linux. La risposta di Wikipedia è probabilmente più generale.

Sul primo punto, puoi dire con certezza che l'ABI dipende dalla piattaforma. Che cosa significa "piattaforma" può variare - può significare hardware fisico, può significare un qualche tipo di macchina virtuale, ecc. L'ABI può dipendere in qualche misura variabile dal linguaggio e dal compilatore - che a sua volta dipende dalla piattaforma. Se l'ABI è in parte definito dall'interfaccia utente dipende da quanto sono vicini la piattaforma e l'O / S.

Dato che l'ABI è sostanzialmente implicito nel modo in cui l'assemblatore generato (o altro codice) opera, la generazione del codice (traduzione da C o qualsiasi altro da assemblatore) deve essere a conoscenza dell'ABI. Ad esempio, il layout dello stack frame per una chiamata di funzione, in particolare il layout dei parametri, viene implementato dalle istruzioni dell'assemblatore che riservano lo spazio necessario e copiano i valori dei parametri in quello spazio.

Quando si codifica in un linguaggio di alto livello, è molto raro avere bisogno di conoscere l'ABI in ogni dettaglio, ma è è a volte necessario per specificare alcune opzioni relative all'ABI. Un esempio, in C ++ e rivolto a un PC Windows, è l'uso di flag di convenzione di chiamata come pascal , stdcall e fastcall . Questi sono spesso necessari quando si collega il codice scritto in un'altra lingua o si utilizza un altro compilatore (spesso i servizi del sistema operativo), per garantire che l'ABI del chiamante corrisponda al chiamato ABI. Più raramente, questi possono essere specificati per ragioni di ottimizzazione, come ad es. alcune convenzioni di chiamata possono essere più efficienti di altre in particolari circostanze.

Se si sta codificando in assembler e si collega ai sistemi operativi o al codice scritto in un'altra lingua, sarà necessario utilizzare gli ABI corretti per tali componenti esterni. Tuttavia, all'interno del tuo modulo assembler, sei libero di fare ciò che vuoi - in effetti, di inventare il tuo ABI, dipendente solo dai limiti della macchina reale o virtuale.

I compilatori possono anche creare le proprie "convenzioni di chiamata personalizzate" dove sanno che una funzione può essere chiamata solo all'interno dello stesso modulo (file oggetto) dove è definita. Questo è tipicamente fatto per ragioni di ottimizzazione. Ad esempio, potrebbe essere possibile evitare di salvare i registri che non verranno utilizzati all'interno di quella funzione. In un modo limitato, quindi, i compilatori possono improvvisare un ABI.

Tuttavia, questo è probabilmente un abuso del termine "ABI" - queste "interfacce" improvvisate per definizione non sono affatto all'interfaccia di un modulo.

Esistono varie convenzioni standard per varie piattaforme. A volte questi sono strettamente imposti dalla piattaforma stessa, ad esempio gli ABI utilizzati per le macchine virtuali Java e .NET. In altri casi, gli ABI standard di fatto sono definiti da un particolare compilatore popolare.

Immagino che lo stato di ABI sulla piattaforma PC Windows sia il più complesso, a causa della lunga storia con i compilatori concorrenti per lingue diverse e con almeno Windows a 32 bit che supporta ancora anche programmi MS-DOS antichi. Ma ci sono sistemi operativi molto più vecchi, ovviamente, che sono stati usati su piattaforme hardware molto più varie - Unix è un caso ovvio - quindi potrei facilmente sbagliarmi.

    
risposta data 01.08.2011 - 05:26
fonte

Leggi altre domande sui tag