Compilación del módulo Kernel y KBUILD_NOPEDANTIC

Question

Me he dado cuenta de que los núcleos recientes (a partir de 2.16.24?) No les gusta si CFLAGS se cambia en el archivo Kbuild del módulo externo. Si se cambia CFLAGS se le emitió el siguiente error de sistema Linux kernel kbuild:

scripts/Makefile.build:46: *** CFLAGS was changed in "/some/path". Fix it to use EXTRA_CFLAGS. Stop. 

De here:

módulos externos tienen en algunos casos opción de gcc modifed modificando CFLAGS. Esto nunca se ha documentado y fue una mala práctica.

Adicional email de LKML.

¿Por qué es mala idea? ¿Qué es racional?

Answer 1

Linux makefiles compilar CFLAGS de una manera apropiada para el kernel.
Reemplazando CFLAGS significa que agrega algunos indicadores y puede eliminar algunos indicadores. Algunos de los indicadores eliminados pueden ser importantes para la compilación correcta.

Answer 2

En primer lugar, vale la pena mencionar que EXTRA_CFLAGS ha quedado obsoleto hace un tiempo y se reemplaza por ccflags-y. Puede leer sobre la intención de ccflags-y en Documentation/kbuild/makefiles.txt, sección 3.7.

Básicamente, esta variable le permite agregar configuraciones al conjunto de indicadores de compilación C, dentro del alcance del archivo donde está asignado únicamente. Se supone que no debe cambiar las banderas globales, porque podría tener un impacto global más allá de su propio archivo MAKE, lo que se considera una mala práctica. El cheque que menciona verifica que, de hecho, los indicadores globales no se cambiaron con los archivos make incluidos.

Es interesante comprobar cómo ccflags-y, anteriormente conocido como EXTRA_CFLAGS, termina siendo utilizado en el proceso de compilación. Trazando algunos puntos relevantes (pero no todos, porque eso se deja como ejercicio para el lector ;-)) muestra lo siguiente:

EXTRA_CFLAGS todavía se puede utilizar, de acuerdo con scripts/Makefile.lib

1 # Backward compatibility 
2 asflags-y += $(EXTRA_AFLAGS) 
3 ccflags-y += $(EXTRA_CFLAGS) 

El mismo archivo muestra cómo ccflags-y termina en las banderas de compilación C (y también le muestra que usted tiene otra variable a su disposición, llamado CFLAGS_<filename>.o):

104 orig_c_flags = $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS) $(KBUILD_SUBDIR_CCFLAGS) \ 
105     $(ccflags-y) $(CFLAGS_$(basetarget).o) 
106 _c_flags  = $(filter-out $(CFLAGS_REMOVE_$(basetarget).o), $(orig_c_flags)) 
... 
133 __c_flags  = $(_c_flags) 
... 
147 c_flags  = -Wp,-MD,$(depfile) $(NOSTDINC_FLAGS) $(LINUXINCLUDE)  \ 
148     $(__c_flags) $(modkern_cflags)       \ 
149     -D"KBUILD_STR(s)=\#s" $(basename_flags) $(modname_flags) 

Luego, en scripts/Makefile.build, el borrador regla ilation se define:

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

Tenga en cuenta que estos son todos de forma recursiva las variables ampliada, utilizando = y no :=, lo que significa que su propio valor de ccflags-y se inserta en las banderas C cuando se define en su propio makefile.

Por último, aproximadamente KBUILD_NOPEDANTIC, que mencionas en el título pero no en la pregunta real.Esta prueba de cambio de valor de CFLAGS se puede desactivar al dar cualquier valor KBUILD_NOPEDANTIC - ver scripts/Makefile.build

47 ifeq ($(KBUILD_NOPEDANTIC),) 
48   ifneq ("$(save-cflags)","$(CFLAGS)") 
49     $(error CFLAGS was changed in "$(kbuild-file)". Fix it to use ccflags-y) 
50   endif 
51 endif 

Los archivos referenciados en esta respuesta fueron recuperados toda la actualidad.

Ahora ... no siendo un experto en esta área y mirando más allá en los makefiles después de escribir toda esta historia, hay algo que tampoco entiendo. Me parece que CFLAGS no se usa en el sistema de compilación (ni implícita ni explícitamente), pero KBUILD_CFLAGS sí. Así que me pregunto si esta verificación de cambios en CFLAGS en realidad debería ser una verificación de cambios en KBUILD_CFLAGS en su lugar.