2012-10-16 14 views
9

Objective-C ha un runtime che traduce la sua sintassi in funzioni organizzate e compilate. C ha una libreria runtime? Inoltre, se qualcuno può rispondere alla domanda, quali sono i passi che GCC prende durante la compilazione C? per esempio. main.c >> >> main.s main.binIl linguaggio di programmazione C ha un runtime?

+3

http://en.wikipedia.org/wiki/C_runtime –

+0

Microsoft lo chiama un runtime. http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.110).aspx –

+2

Sembra non essere chiaro su cosa funzioni un sistema di runtime. Non "traduce [...] la sintassi in funzioni"; questo è il lavoro del compilatore. Il runtime in ObjC fornisce principalmente l'infrastruttura dell'oggetto: creazione di classi, invio di messaggi e così via. (Ci sono altri pezzi, ovviamente.) –

risposta

4

Sì, il linguaggio C presenta una libreria standard; cioè, un certo numero di macro, routine e tipi standard che si possono usare nei suoi programmi, a parte quelli del linguaggio principale stesso.

Nelle implementazioni popolari, esiste un file di libreria separato contenente il codice per la libreria standard C. Ad esempio, in ambienti GNU/Linux, la libreria GNU C (libc) è quasi sempre presente. Microsoft fornisce la libreria di runtime msvcrt.dll per il sistema Windows e così via.

Inoltre, la libreria C standard potrebbe non essere disponibile nelle implementazioni indipendenti. A volte è possibile compilare un programma senza collegarsi alla libreria standard C dal proprio sistema. Ad esempio, l'API di Windows è nota per il suo comportamento come ambiente di programmazione C indipendente (anche se potrebbe essere necessario collegarsi ad altre librerie di sistema specifiche di Windows).

Riguardo GCC, la seguente illustra brevemente pipeline compilazione:

  1. La sorgente di ingresso viene pre-elaborato con GNU cpp, risultante in un'unità di traduzione. (In realtà, come Basile sottolineato, oggi non si crea alcun processo cpp; l'intera opera preelaborazione avviene entro cc1 Tuttavia, il comportamento risultante è probabilmente la stessa con cpp..)
  2. L'unità di traduzione viene quindi interpretata e compilato in assembly source con GCC cc1;
  3. La sorgente dell'assieme viene quindi assemblata in codice oggetto con GNU as;
  4. Infine, i file oggetto e le librerie sono collegati tra loro per produrre un'immagine binaria con GNU ld.

Naturalmente, ognuno di questi passaggi può essere modificato o non eseguito affatto a seconda delle opzioni del driver; quanto sopra è solo una spiegazione approssimativa del processo generale.

+0

Questo è sbagliato oggi: con il recente GCC (anche GCC dei primi anni 2000), la pre-elaborazione e la compilazione sono fatte da 'cc1' e non c'è più alcun processo' cpp' –

+0

Grazie per aver chiarito. Correggerò l'informazione – alecov

1

C ha una libreria standard (ad esempio, strlen, malloc, etc.)

I passi sono: compilare il codice che utilizza la libreria standard, quindi collega il tuo codice alla libreria standard. libc può essere contenuto in una libreria statica o in una libreria dinamica, a seconda; di solito entrambi sono disponibili.

1

C ha una libreria standard (libc su Linux, che fornisce funzioni standard come quelli di <stdio.h> quali fprintf e in <stdlib.h> quali malloc e anche tutte le chiamate di sistema), e anche quando si utilizza gcc in modalità free standing con gcc -ffreestanding (ad esempio per compilare uno libc o un kernel) collega una piccola libreria libgcc che fornisce la funzionalità integrata nella lingua (ad es. Aggiunta di 64 bit su piattaforme a 32 bit).

Per sapere cosa sta facendo il comando gcc, passarlo al flag -v.(Non dimenticare di prendere l'abitudine di compilare sempre con -Wall per ricevere gli avvertimenti e -g per ottenere le informazioni di debug), ad es.

% gcc -v -g -Wall hello.c -o hello 
Using built-in specs. 
COLLECT_GCC=gcc 
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper 
Target: x86_64-linux-gnu 
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu 
Thread model: posix 
gcc version 4.7.2 (Debian 4.7.2-4) 
COLLECT_GCC_OPTIONS='-v' '-g' '-Wall' '-o' 'hello' '-mtune=generic' '-march=x86-64' 
/usr/lib/gcc/x86_64-linux-gnu/4.7/cc1 -quiet -v -imultiarch x86_64-linux-gnu hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -g -Wall -version -o /tmp/ccsWt3UC.s 
GNU C (Debian 4.7.2-4) version 4.7.2 (x86_64-linux-gnu) 
    compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" 
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../x86_64-linux-gnu/include" 
#include "..." search starts here: 
#include <...> search starts here: 
/usr/lib/gcc/x86_64-linux-gnu/4.7/include 
/usr/local/include 
/usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed 
/usr/include/x86_64-linux-gnu 
/usr/include 
End of search list. 
GNU C (Debian 4.7.2-4) version 4.7.2 (x86_64-linux-gnu) 
    compiled by GNU C version 4.7.2, GMP version 5.0.5, MPFR version 3.1.0-p10, MPC version 0.9 
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 
Compiler executable checksum: c5f63dedeacd449634699df94fe3d914 
COLLECT_GCC_OPTIONS='-v' '-g' '-Wall' '-o' 'hello' '-mtune=generic' '-march=x86-64' 
as -v --64 -o /tmp/ccO5i3pU.o /tmp/ccsWt3UC.s 
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.22 
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/ 
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.7/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../:/lib/:/usr/lib/ 
COLLECT_GCC_OPTIONS='-v' '-g' '-Wall' '-o' 'hello' '-mtune=generic' '-march=x86-64' 
/usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id --no-add-needed --eh-frame-hdr -m elf_x86_64 --hash-style=both -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o hello /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../.. /tmp/ccO5i3pU.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.7/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o 

noti che collect2 è il linker avvolto a fare cose aggiuntive, e che libc.so si abitua da quasi tutti i eseguibile Linux (perché è avvolgente syscalls).

Problemi correlati