yocto编译linux社区5.10版本的坎坷

作为菜鲲的我，基于meta-intel的bsp进行修改，
精简后的linux-intel_5.10.bb内容如下：

require recipes-kernel/linux/linux-yocto.inc
FILESEXTRAPATHS:prepend := "${THISDIR}/linux-intel:"

KBRANCH = "master"
LINUX_VERSION = "5.10"
SRCREV_machine = "2c85ebc57b3e1817b6ce1a6b703928e113a90442"

KERNEL_SOURCE_URI = "git:///workdir/smk/GIT_DIR/linux;name=machine;branch=${KBRANCH};protocol=file;"
KERNEL_CONFIG_URI = "file://x86_64_defconfig"

SRC_URI = " \ 
           ${KERNEL_SOURCE_URI} \
           ${KERNEL_CONFIG_URI} \
          "
PV = "${LINUX_VERSION}+git${SRCPV}"

KCONF_BSP_AUDIT_LEVEL = "2" 

COMPATIBLE_MACHINE ?= "intel-corei7-64"

LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"

DEPENDS += "elfutils-native openssl-native util-linux-native"

同时需在local.conf指定MACHINE = “intel-corei7-64”
然后，在编译环境下执行bitbake virtual/kernel.
结果报错，

随后查看log.do_compile日志，搜索Error关键字，结果如下

从以上错误信息来看，我并没有发现明确的报错原因（可能我比较菜）。
由于5.10的内核编译没问题，编译命令如下

make ARCH=x86_64 defconfig
make ARCH=x86_64 -j40

前面yocto的linux bb文件里的x86_64_defconfig就是上面生成.config，因此我怀疑是内核的问题而不是配置文件，我做了以下尝试验证了我的猜想。
1.替换intel-corei7-64的config，换成其自己（yocto）编译生成的.config，成功！
2.替换intel-corei7-64的config，换成linux社区的x86_64_defconfig，成功！
3.替换intel-corei7-64的kernel的源换成linux-yocto的，成功！
4.替换intel-corei7-64的kernel的源换成linux.org的，失败！
验证猜想正确。
之后就是找出intel的linux和yocto维护的linux内核库对社区的linux 5.10作了哪些改动，这里我选择了intel的linux-intel-lts与linux.org做对比。
linux.org 的5.10版本的commit很好确定，linux-intel-lts由于commit众多，根据二分法最终找到了一个最早的可行的版本(yocto可以编译成功)5.10.12，然后对比5.10.11和5.10.12发现有40+文件的改动，突然在改动的文件中发现了tools/objtool/elf.c tools/objtool/Makefile。忽然联想到之前的错误信息中有一个objtool
，根据搜索关键字missing symbol table，最终确定了是tools/objtool/elf.c的改动导致。

通过把"return -1;“改为"return 0;”，成功编译并运行！
秉着知其然，知其所以然的态度，整理了一下问题。（问GPT）
yocto在编译的时候，通常会在编译过程中使用 tools/objtool/objtool 工具进行 check --retpoline --uaccess 操作，以验证内核的 RETPOLINE 和 uaccess 代码是否正确。这是由 Yocto 中 meta/classes/kernel.bbclass 类定义的，其中会将 objtool 工具用于内核构建。
在内核 recipe 文件中，可以通过设置 KERNEL_CHECK_OBJTOOL 变量来控制是否执行 objtool check 操作

KERNEL_CHECK_OBJTOOL = "no"

上面的示例将禁用 objtool check 操作。

需要注意的是，objtool check 操作会在编译过程中增加一定的时间和资源消耗，因此如果对编译速度有要求，可以考虑禁用该操作。但是，为了确保内核的安全性和稳定性，建议在编译内核时启用 objtool check 操作。
我测试了一下，并不work，GTP-4啥时候免费啊！！！
于是，只能自己动手，对比yocto的编译选项，想了解是如何导致开启了objtool check的功能，通过执行 bitbake virtual/kenel -e 查到

选项如此之多，询问GPT，这些选项没有跟obj相关的。我尝试在conf/local.conf 设置EXTRA_OEMAKE = " ", 也不work。
去yocto官方英文文档也没查到跟objtool相关的线索，唉。
yocto可太难了~~~