Supponiamo di avere una catena di strumenti cross-compilation che produce file binari per l'architettura ARM.Quali sono le differenze tra compilazione e compilazione bare-metal C/C++ per un sistema operativo specifico (Linux)?
tuo tool-chain è come questo (in esecuzione su una macchina X86_64 con Linux):
- braccio-linux-gnueabi-gcc.exe: per il cross-compilazione per Linux, in esecuzione su ARM.
- arm-gcc.exe: per il targeting cross-compilation bare-metal ARM.
... e la pletora di altri strumenti per cross-compilation su ARM.
I punti che mi interessano sono:
- differenze (E) ABI tra i binari (se presente)
- limitazioni in caso di bare-metal (come le allocazioni di memoria dinamica, utilizzo di costruttori statici in caso di C++, modelli di threading, ecc.)
- differenze a livello binario tra i 2 casi in termini di informazioni specifiche per ciascuno di essi (come il supporto di informazioni di debug, ecc.);
Che suona come "differenza tra il mio piccolo programma e il mio sistema operativo" ... – deviantfan
@deviantfan: suonare più come "Posso usare tutte le 'caratteristiche normali' di C/C++ che io sono abituato a per il firmware (sviluppo di metallo nudo? " Dopo aver letto questo articolo qui: http://www.state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf Ho notato alcune limitazioni del bare-metal C/C++. Ce ne sono altri (e anche le differenze)? :) – Liviu
Per * real bare metal *, è necessario scrivere un layer di portabilità per * newlib *. Su Gnu Linux, * eglibc * o [* glibc *] (http: //en.wikipedia.org/wiki/GNU_C_Library) è usato. Fondamentalmente, la tua domanda è qual è la differenza. Ce ne sono 1000 Vuoi usare 'mmap()'? Ecc. Le differenze binarie/compilatore non contano (soprattutto). Sono le librerie "C" completamente diverse. File I/O? –