Breve spiegazione per i file eseguibili in una GNU / Clang Toolchain?

2

Capisco approssimativamente che cc, ld e altre parti sono chiamate in una certa sequenza secondo schemi come Makefile ecc. Alcuni di questi comandi sono usati per generare quelle configurazioni e Makefile. E alcuni altri strumenti sono usati per gestire le biblioteche. Ma a cosa servono le altre parti? Come vengono chiamati in questo processo? Quale strumento userebbe vari generatori di parser? Quale parte è facoltativa? Perché?

C'è un breve sommario che spiega come gli strumenti di una toolchain GNU o LLVM / Clang sono organizzati e chiamati in un progetto C / C ++?

Grazie in anticipo.

EDIT:

Ecco un elenco di file eseguibili per Clang / LLVM su Mac OS X:

ar clang dsymutil gperf libtool nmedit rpcgen unwinddump come clang ++ dwarfdump gprof lorder otool segedit vgrind asa cmpdylib dyldinfo indent m4 pagestuff size what bison codesign_allocate flex install_name_tool mig ranlib strip yacc c ++ ctags flex ++ ld mkdep rebase unifdef cc ctf_insert gm4 lex nm redo_prebinding unifdefall

    
posta ZhangChn 08.11.2012 - 18:20
fonte

1 risposta

2

La maggior parte di questi strumenti non viene utilizzata in un progetto standard, io stesso non ne ho mai visto la metà.

Questo è il flusso di lavoro di base, in termini di processi effettivi eseguiti:

gcc
|
v
cc1 -> as -> collect2 -> ld

Questo da solo non ti dice molto. Non c'è cpp (il preprocessore) - che è integrato in cc1 . cc1 è di per sé il backend e il compilatore "reale" - il gcc binario è un frontend per tutti gli strumenti che svolgono il lavoro effettivo. cc1 è il backend del preprocessore / compilatore, che viene compilato per il montaggio. as è l'assemblatore, che produce file oggetto. collect2 (Mi sono dimenticato di me stesso, e ne sono stato informato solo perché ho eseguito un strace ) assistenza nell'organizzazione del codice di avvio nell'eseguibile (da qui ). Infine, ld collega i file e le librerie di oggetti all'eseguibile finale.

Per l'uso effettivo di questi singoli componenti, è in genere un'idea migliore chiamare gcc e lasciare che capisca cosa fare. Ad esempio, puoi eseguire gcc -S su un file .c per produrre il file .s assemply o gcc -E solo per preelaborare il file sorgente.

In sostanza, man gcc è ciò che vuoi leggere. O almeno sfogliare.

    
risposta data 11.11.2012 - 20:11
fonte

Leggi altre domande sui tag