Quels sont les codes tels que CC, LD et CC lors de la compilation du kernel Linux?

En compilant Linux à partir de rien, je me rends compte que des codes de compilation apparaissent lors de la compilation.

Par exemple, CC filename, LD filename, CC [M] filename.

Que signifient ces codes?

Les différentes marques spécifient ce qui suit

  • [CC] – Comstack le fichier C dans un fichier object désigné. Le fichier object contient le code assembleur d’archive de ce fichier .c. Comme il pourrait également faire référence à des parties hors de son champ d’application. Par exemple, appeler une autre fonction dans un autre fichier .c. Les appels de fonction sont laissés ouverts dans le fichier object, qui est ensuite inclus par l’éditeur de liens. Donc
  • [LD] est le processus consistant à lier les objects compilés et à câbler les appels de fonction laissés ouverts par le compilateur. Cependant, de nombreuses parties sont liées entre elles en tant que partie centrale du kernel, tandis que certaines parties sont exclues. Et ainsi vous voyez
  • [CC (M)] pour les parties qui sont compilées en tant que points à charger dans le kernel à l’exécution. Mais qui ne sont pas liés ensemble dans la partie monolithique du kernel. Mais au lieu de cela peut être inséré lorsque le kernel est démarré.

Prenons un exemple spécifique et IHEX ce qu’il fait dans le kernel 4.1, par exemple IHEX .

Trouvez ce que fait un code

Il suffit de courir:

 make SHELL='sh -x' 

Comment ça marche: https://stackoverflow.com/a/32010960/895245

Si nous IHEX la sortie pour IHEX , nous trouvons les lignes:

 + echo IHEX firmware/e100/d101s_ucode.bin IHEX firmware/e100/d101s_ucode.bin + objcopy -Iihex -Obinary /home/ciro/git/kernel/src/firmware/e100/d101s_ucode.bin.ihex firmware/e100/d101s_ucode.bin 

donc nous concluons que IHEX fait une objcopy -Iihex .

Trouver où un code est défini

Chaque commande du kernel doit être définie avec quelque chose comme:

 quiet_cmd_ihex = IHEX $@ cmd_ihex = $(OBJCOPY) -Iihex -Obinary $< $@ $(obj)/%: $(obj)/%.ihex $(call cmd,ihex) 

pour que les parameters de verbosité (par exemple, V=1 et make -s ) fonctionnent.

Donc en général, il suffit de

 git grep 'cmd.* = CODE' 

trouver CODE .

J'ai expliqué en détail comment ce système fonctionne à: https://stackoverflow.com/a/32023861/895245

Obtenez la liste de tous les codes

 make | grep -E '^ ' | sort -uk1,1 

CC et CC [M]

Défini dans scripts/Makefile.build :

 quiet_cmd_cc_o_c = CC $(quiet_modtag) $@ cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $< 

et le [M] provient des variables spécifiques à la cible :

 $(real-objs-m) : quiet_modtag := [M] $(real-objs-m:.o=.i) : quiet_modtag := [M] $(real-objs-m:.o=.s) : quiet_modtag := [M] $(real-objs-m:.o=.lst): quiet_modtag := [M] $(obj-m) : quiet_modtag := [M] 

Il est ensuite appelé par:

 $(obj)/%.o: $(src)/%.c $(recordmcount_source) FORCE [...] $(call if_changed_rule,cc_o_c) define rule_cc_o_c [...] $(call echo-cmd,cc_o_c) $(cmd_cc_o_c); \ 

if_changed_rule est défini dans scripts/Kbuild.include comme:

 if_changed_rule = $(if $(ssortingp $(any-prereq) $(arg-check) ), \ @set -e; \ $(rule_$(1))) 

et Kbuild.include est inclus dans le Makefile de niveau supérieur.

LD

Il existe quelques versions, mais la plus simple semble être:

 quiet_cmd_link_o_target = LD $@ cmd_link_o_target = $(if $(ssortingp $(obj-y)),\ $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \ $(cmd_secanalysis),\ rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@) $(builtin-target): $(obj-y) FORCE $(call if_changed,link_o_target) 

et dans scripts/Kbuild.include :

 # Execute command if command has changed or prerequirejsite(s) are updated. # if_changed = $(if $(ssortingp $(any-prereq) $(arg-check)), \ @set -e; \ $(echo-cmd) $(cmd_$(1)); \ printf '%s\n' 'cmd_$@ := $(make-cmd)' > $(dot-target).cmd) 

Il devrait montrer:

  • CC lors de la compilation d’une partie centrale du kernel
  • CC [M] lors de la compilation d’un module
  • LD lors de la liaison