linux kernel module linker warnings: "*** Advertencia: <function> [<module>] undefined!" - ¿Alguna forma de deshacerse de ellos?

Question

Al compilar los módulos del núcleo de Linux que dependen unos de otros, enlazador da advertencias de símbolos indefinidos como

Building modules, stage 2. 
MODPOST 
*** Warning: "function_name1" [module_name] undefined! 
*** Warning: "function_name2" [module_name] undefined! 
*** Warning: "function_name3" [module_name] undefined! 

Los símbolos sin resolver se resuelven tan pronto como el módulo se inserta en núcleo usando insmod o modprobe. Sin embargo, ¿hay alguna forma de deshacerse de la advertencia del enlazador?

He leído 3 Google SERP's sobre este tema, parece que nadie sabe la respuesta. ¿Se supone que estas advertencias de enlazador son así cuando construyes un módulo kernel?

Answer 1

No, no lo son. Aunque construyas tu código en el árbol o fuera de él, este mensaje no debería mostrarse. Creo que debes arreglar tu archivo Makefile. Aquí hay un ejemplo de archivo MAKE. No es perfecto, sino que se utiliza para trabajar (hasta 2.6.26, no lo probamos ya):

ifneq ($(KERNELRELEASE),) 
# We were called by kbuild 

obj-m += mymodule.o 
mymodule-objs := mymodule_usb.o a.o b.o c.o 

else # We were called from command line 

KDIR := /lib/modules/$(shell uname -r)/build 
PWD := $(shell pwd) 

default: 
    @echo ' Building FOO drivers for 2.6 kernel.' 
    @echo ' PLEASE IGNORE THE "Overriding SUBDIRS" WARNING' 
    $(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules 

install: 
    ./do_install.sh *.ko 

endif # End kbuild check 

clean: 
    rm -f -r *.o *.ko .*cmd .tmp* core *.i 

Para más documentación, se puede comprobar el árbol del núcleo, el proceso es kbuild documented

Answer 2

Finalmente, lo tengo. Gracias a shodanex por ponerme en el camino correcto.

Actualización: Tenga mucho cuidado al aplicar esta revisión a construye para versiones anteriores de núcleo, ya que hay un error en el archivo de Makefile.modpost en las versiones anteriores del núcleo que hace que su construcción se portan mal y construir objetivos incorrectos cuando especifica KBUILD_EXTMOD opción.

Debe especificar las rutas a la fuente de los módulos de los que depende en KBUILD_EXTMOD make parameter.

Say, que tiene un módulo foo que depende de los símbolos del módulo de barra de.

Los archivos de origen para foo están en foo/módulo/ y archivos de origen para la barra están en bar/módulo/

El comando make en Makefile para foo probablemente se parece

make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \ 
    M=`pwd`/module \ 
    modules 

(la línea exacta puede diferir en su proyecto).

cambiarlo a

make ARCH=$$ARCH CROSS_COMPILE=$$CROSS_COMPILE -C $$LINUX_DIR \ 
    M=`pwd`/module \ 
    KBUILD_EXTMOD=`pwd`/../bar/module \ 
    modules 

(que añade la pwd = /../bar/module \ línea de KBUILD_EXTMOD, donde pwd /../bar/module es un camino a fuentes de módulo del kernel que dependemos sucesivamente.

Uno esperaría KBUILD_EXTRA_SYMBOLS parámetro para trabajar de esta manera, sin embargo, es KBUILD_EXTMOD.

Answer 3

Mi necesidad de adaptarse a su árbol. En nuestra fuente creamos un SYMBOLSDIR que es un camino para todos los módulos

SYMBOLSDIR = 'algún camino'

maquillaje (igual al anterior ejemplo) $ MODVERDIR = $ módulos (SYMBOLSDIR) (KERNELDIR)

Answer 4

uso KBUILD_EXTRA_SYMBOLS de la siguiente manera: KBUILD_EXTRA_SYMBOLS = 'su ruta del módulo'/Module.symvers

Answer 5

relacionadas con la técnica anterior de utilizar KBUILD_EXTMOD, y la cuestión de qué versiones del kernel funciona bajo:

• andycjw indicó que no funcionó para él en 2.6.12
• No funcionó para mí en 2.6.15 (me rompió el módulo de acumulación)
• Mirando a través del núcleo de cometa, veo una serie de los cambios en Makefile.modpost que parecen estar relacionados en 2.6.26 y 2.6.28, por lo que espero que uno de ellos sea el límite.