Perché abbiamo bisogno di un formato per i file eseguibili binari

Ci sono molti casi d'uso per metadati come questo, alcuni sono "necessari" e altri sono piacevoli da avere.

• Al minimo indispensabile (se il codice non è indipendente dalla posizione, che non è ancora l'impostazione predefinita), il caricatore deve sapere a quale indirizzo deve andare il codice.
• Su alcune piattaforme (tra cui alcune in uso comune oggi, come i microcontroller integrati), c'è una memoria separata per il codice e per i dati. Il caricatore deve essere in grado di distinguere il codice dai dati per mettere in memoria il codice da cui la CPU può eseguire e i dati in memoria che la CPU può leggere e scrivere.
• Per i file binari che non sono file eseguibili ma piuttosto librerie, è necessaria una tabella dei simboli per abilitare il codice che utilizza quella libreria per chiamare la funzione corretta.
• Anche se non c'è memoria fisicamente separata per codice e dati, è utile impostare la memoria in modo che i dati non siano eseguibili e il codice non sia scrivibile. Certo, potresti lasciare che il programma lo faccia da solo durante l'inizializzazione, ma questo è soggetto a errori, duplicazione di codice inutile senza una buona ragione.
• Conoscere lo scopo delle sezioni di dati può consentire l'ottimizzazione. Ad esempio, se si dispone di una sezione .bss separata per i dati che devono essere inizializzati a zero, un sistema operativo moderno può pigramente allocare pagine zero per migliorare i tempi di creazione del processo. Se si dispone di una sezione .rodata per i dati di sola lettura, questi dati possono andare in una ROM separata (se il computer ha una ROM), liberando RAM e possibilmente apportando altri benefici. Quando si eseguono più istanze di un programma, i dati presunti di sola lettura (incluso il codice) possono essere condivisi tra tali processi.

Sono sicuro che ci sono più motivi, non ho molta familiarità con le decisioni di progettazione che vanno in un caricatore.

Perché vogliamo che i nostri computer facciano di più che eseguire solo un programma fisso.

Avere un flusso di opcode in memoria e passarci all'infinito va bene se si ha una macchina monouso. Ma su un computer reale, vuoi ottenere cose come

• avere una chiamata binaria un'altra e trasferire il controllo ad essa
• avere una chiamata binaria e ricontrollare il controllo dopo la sua chiusura
• multi-task tra molti programmi e farlo apparire come se fossero in esecuzione simultaneamente
• assegnare a un programma i diritti di monitoraggio o amministrazione su un altro programma per limitare le cose che l'altro programma può eseguire
• e molto, molto di più!

Per tutto questo, è necessario un software eseguibile che consideri altri software eseguibili come i suoi dati di input, il che significa che devi essere in grado di esprimere cose come "questo codice possiede quell'indirizzo di memoria" o "quei due processi sono veramente istanze dello stesso programma e possono condividere il loro segmento di dati statici ".

Un sacco di byte in un file binario è , infatti, una stringa di codice macchina, ma tutto il resto deve essere memorizzato in qualche modo, e un formato di file binario è solo una specifica dicendo come farlo.

L'impostazione di alcune aree come dati consente a alcune architetture di rilevare quando si tenta di eseguirle (e quindi lasciare che il sistema operativo lo uccida).

Esiste anche una progettazione dell'architettura che suddivide il codice e i dati in spazi di indirizzi separati in modo che il file debba fare la differenza tra i 2 altrimenti non sarebbe in grado di accedere ai dati. Le restrizioni del formato eseguibile derivano dal cercare di essere compatibili tra loro (assumendo gli stessi set di istruzioni).