調試記錄 | Linux 內核靜態(tài)庫封裝問題
本文轉載自微信公眾號「漫談嵌入式」，作者Vinson 。轉載本文請聯(lián)系漫談嵌入式公眾號。
背景
對于靜態(tài)庫的封裝，大多數(shù)情況在應用層應用的封裝的比較多，用起來比較熟悉。不過，在嵌入式開發(fā)中，有些時候，需要將一些私有修改隱藏起來，特別是，內核中的一些修改。
此時需要在內核態(tài)制作靜態(tài)庫，然后鏈接到整個內核文件中。
對于一般(沒有復雜的內核依賴關系)的內核靜態(tài)庫的封裝，直接安裝應用層封裝即可。
對于內核中一些高級驅動的私有修改，在進行封裝時，就需要格外注意了，包括正確編譯，頭文件交叉引用，如果正確被鏈接到內核中，而不是被編譯器忽略掉了。
封裝問題
我們以 usb_f_uvc.ko 這個uvc function driver為例，來分析，內核靜態(tài)庫的封裝(假設，以下文件有修改或者定制)。最終，將usb_f_uvc.ko 打包成一個 靜態(tài)庫，鏈接到內核里面。
- # kernel/drivers/usb/gadget/function/Makefile
- usb_f_uvc-y := f_uvc.o uvc_queue.o uvc_v4l2.o uvc_video.o uvc_configfs.o
- obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o
編譯
我們將需要的文件，復雜到一個目錄下，修改Makefile
- # Makefile
- # 可換成自己的工具鏈
- CROSS_COMPILE ?= arm-linux-gnu-
- CC := $(CROSS_COMPILE)gcc
- LD := $(CROSS_COMPILE)ld
- AR := $(CROSS_COMPILE)ar
- CP := cp
- RM := rm
- # 修改正確的kernel 路徑
- KERNEL_PATH := xxxx/kerenl
- # 獲取gcc 版本
- CC_PATH := ${shell which $(CC)}
- CROSS_COMPILE_PATH := ${shell dirname $(CC_PATH)}
- CFLAGS := -nostdinc -isystem $(CROSS_COMPILE_PATH)/../lib/gcc/arm-linux-gnu/7.2.0/include
- # 頭文件順序很重要，換成自己平臺的
- INCLUDE = -I$(KERNEL_PATH)/arch/arm/include \
- -I$(KERNEL_PATH)/arch/arm/include/generated/uapi \
- -I$(KERNEL_PATH)/arch/arm/include/generated \
- -I$(KERNEL_PATH)/include \
- -I$(KERNEL_PATH)/arch/arm/include/uapi \
- -I$(KERNEL_PATH)/include/uapi \
- -I$(KERNEL_PATH)/include/generated/uapi/ \
- -include $(KERNEL_PATH)/include/linux/kconfig.h
- INCLUDE += -I$(KERNEL_PATH)/arch/arm/xxxx/core/include \
- -I$(KERNEL_PATH)/arch/arm/xxxx/soc-xxx/include \
- -I$(KERNEL_PATH)/arch/arm/include/asm/mach-generic
- #CFLAGS += -fno-delete-null-pointer-checks -Wno-maybe-uninitialized -Wno-frame-address -Wno-format-truncation \
- #-Wno-format-overflow -Wno-int-in-bool-context -Os --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO \
- #-Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -Wno-unused-const-variable \
- #-fomit-frame-pointer -fno-var-tracking-assignments -Wdeclaration-after-statement \
- #-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int \
- #-Werror=strict-prototypes -Werror=date-time
- CFLAGS += -DEXPORT_SYMTAB
- # 這個一定要加
- CFLAGS += -D__KERNEL__
- CFLAGS += $(INCLUDE)
- OBJS := uvc_queue.o uvc_v4l2.o uvc_video.o f_uvc.o uvc_configfs.o
- ARFLAG := -rcs
- LIB_TARGET := libxxx.a
- TARGET := libxxx.hex
- all: $(TARGET)
- %.o:%.c
- $(CC) $(CFLAGS) -o $@ -c $^
- $(TARGET): $(LIB_TARGET)
- $(CP) $(LIB_TARGET) $(TARGET)
- $(CP) -vf $(TARGET) $(KERNEL_PATH)/drivers/usb/gadget/function/
- $(LIB_TARGET): $(OBJS)
- $(AR) $(ARFLAG) $@ $^
- clean:
- find . -name "*.o" | xargs rm -r
- $(RM) -vf $(LIB_TARGET) $(TARGET)
- install:
- $(CP) -vf $(TARGET) $(KERNEL_PATH)/drivers/usb/gadget/function/
Makefile 參數(shù)和頭文件如何來?
事實上，整個內核打包的過程，筆者認為，編譯是最難的一步，特別是第一次接觸的時候。
對于驅動中的各符號和宏的定義，以及頭文件包含是層層套娃，根據(jù)錯誤信息定位，簡直要崩潰。
在這里，筆者建議，先參考【內核編譯參數(shù)選項】，然后在逐一刪減無關選項，這樣會方便很多。
具體操作如下：
- 正常編譯內核：
- touch 修改 f_uvc.c：
- 重新編譯內核：make uImage V=1 > build.txt
- vim build.txt 搜索f_uvc 即可看到編譯信息
使用 make V=1 參數(shù)將編譯的詳細信息輸出，包括頭文件包含順序，gcc 編譯參數(shù)選項等，然后將其添加到我們的Makefie上。最后在對我們的Makfile 做刪減。
添加到內核
- #kernel/drivers/usb/gadget/function/Makefile
- usb_f_uvc-y := libxxx.a
- #obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o
- obj-y += usb_f_uvc.o
- # 防止Make distclean 把所有 .a都清掉了
- $(obj)/libxxx.a: $(obj)/libxxx.hex
- cp $(obj)/libxxx.hex $(obj)/libxxx.a
編譯內核
重新編譯內核，將.a 鏈接到內核。然后燒到板子運行。
運行
實際運行，發(fā)現(xiàn)根本沒有鏈到板子去。
原因分析
查看 EXPORT_SYMBOL
打開 Module.symvers 發(fā)現(xiàn)，uvc 相關的接口并沒有導出來，猜測有可能沒有成功鏈到內核。
- vim Module.symvers
objdump 反匯編
使用objdump 將所有的符號表都輸出來，然后在搜索查看，進一步確認鏈接是否正確。結果發(fā)現(xiàn)也找不到任何符號信息
- arm-linux-gnu-objdump -Dz vmlinux > kernel.dump
此時一個大膽的想法出現(xiàn)了，是否是被編譯器給優(yōu)化掉了?因為是靜態(tài)庫，對于庫文件來說，其本身只是一些接口，自身不能執(zhí)行調用過程。如果接口沒有人調用，那么所有相關的符號是否自動被忽略了?考慮一波對編譯鏈接的理解
分析源碼
- //f_uvc.c
- DECLARE_USB_FUNCTION_INIT(uvc, uvc_alloc_inst, uvc_alloc);
- MODULE_LICENSE("GPL");
- MODULE_AUTHOR("Laurent Pinchart");
這里的 DECLARE_USB_FUNCTION_INIT 很重要。我們，具體展開。
- #define DECLARE_USB_FUNCTION_INIT(_name, _inst_alloc, _func_alloc) \
- DECLARE_USB_FUNCTION(_name, _inst_alloc, _func_alloc) \
- static int __init _name ## mod_init(void) \
- { \
- return usb_function_register(&_name ## usb_func); \
- } \
- static void __exit _name ## mod_exit(void) \
- { \
- usb_function_unregister(&_name ## usb_func); \
- } \
- module_init(_name ## mod_init); \
- module_exit(_name ## mod_exit)
這里看到 module_init 應該很熟悉了，對于我們上面封裝的庫來說，本質上也是一個驅動，是驅動就有對應的入口和出口。
對于內核，所有的入口都被放在 .text.init 處，加載到內核中后會按照相應順序進行初始化。
如果我們，把整個驅動封裝成一個靜態(tài)庫，DECLARE_USB_FUNCTION_INIT 屬于庫的接口，本身不會自己調用。所以內核在鏈接的過程中，發(fā)現(xiàn)沒有調用關系，就自然而然會忽略掉libxxx.a的相關符號。
知道了原因，解決方法就很簡單了。在內核中一定要存在有調用DECLARE_USB_FUNCTION_INIT的地方。
- 方法1：手動調用。不推薦
- 方法2：自動調用。沿用內核驅動模型。將 DECLARE_USB_FUNCTION_INIT 從靜態(tài)庫中剝離出來，其他文件打包成一個庫。
修改如下：
- // entry.c
- #include <linux/kernel.h>
- #include <linux/module.h>
- #include <linux/device.h>
- #include <linux/errno.h>
- #include <linux/list.h>
- #include <linux/mutex.h>
- #include <linux/string.h>
- #include <linux/usb/ch9.h>
- #include <linux/usb/gadget.h>
- #include <linux/usb/video.h>
- #include "u_uvc.h"
- #include "f_uvc.h"
- static struct usb_function_instance *uvc_alloc_inst(void)
- {
- return uvc_alloc_inst_callback();
- }
- static struct usb_function *uvc_alloc(struct usb_function_instance *fi)
- {
- return uvc_alloc_callback(fi);
- }
- DECLARE_USB_FUNCTION_INIT(uvc, uvc_alloc_inst, uvc_alloc);
- MODULE_LICENSE("GPL");
- MODULE_AUTHOR("Laurent Pinchart");
重新修改Makefile
- usb_f_uvc-y := entry.o libxxx.a
- obj-y += usb_f_uvc.o
- #obj-$(CONFIG_USB_F_UVC) += usb_f_uvc.o
- $(obj)/libxxx.a: $(obj)/libxxx.hex
- cp $(obj)/libxxx.hex $(obj)/libxxx.a
這樣重新，編譯內核，就可以用了。以后只需要更新libxxx.a 即可。
總結
本文簡單介紹內核靜態(tài)庫，打包遇到的一些坑。通過一個例子，介紹內核靜態(tài)庫的封裝，以及遇到的問題。
同時也加深了對編譯和鏈接的理解。有關應用層靜態(tài)庫和內核態(tài)的庫在使用上是一樣的，不過在制作時有些許麻煩。
- 頭文件的引用包含
- 編譯參數(shù)選項
- 是否成功鏈接
有關驅動入口的部分，不能做到庫里面，避免踩雷。折騰其他，結果發(fā)現(xiàn)是鏈接時出了問題。
