--- zzzz-none-000/linux-4.4.271/scripts/link-vmlinux.sh 2021-06-03 06:22:09.000000000 +0000 +++ hawkeye-5590-750/linux-4.4.271/scripts/link-vmlinux.sh 2023-04-19 10:22:30.000000000 +0000 @@ -90,6 +90,10 @@ kallsymopt="${kallsymopt} --absolute-percpu" fi + if [ -n "${CONFIG_KALLSYMS_UNCOMPRESSED}" ]; then + kallsymopt="${kallsymopt} --uncompressed" + fi + local aflags="${KBUILD_AFLAGS} ${KBUILD_AFLAGS_KERNEL} \ ${NOSTDINC_FLAGS} ${LINUXINCLUDE} ${KBUILD_CPPFLAGS}" @@ -179,7 +183,7 @@ fi; # final build of init/ -${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init +${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}" kallsymso="" kallsyms_vmlinux="" @@ -196,10 +200,14 @@ # the right size, but due to the added section, some # addresses have shifted. # From here, we generate a correct .tmp_kallsyms2.o - # 2a) We may use an extra pass as this has been necessary to - # woraround some alignment related bugs. - # KALLSYMS_EXTRA_PASS=1 is used to trigger this. - # 3) The correct ${kallsymso} is linked into the final vmlinux. + # 3) That link may have expanded the kernel image enough that + # more linker branch stubs / trampolines had to be added, which + # introduces new names, which further expands kallsyms. Do another + # pass if that is the case. In theory it's possible this results + # in even more stubs, but unlikely. + # KALLSYMS_EXTRA_PASS=1 may also used to debug or work around + # other bugs. + # 4) The correct ${kallsymso} is linked into the final vmlinux. # # a) Verify that the System.map from vmlinux matches the map from # ${kallsymso}. @@ -215,8 +223,11 @@ vmlinux_link .tmp_kallsyms1.o .tmp_vmlinux2 kallsyms .tmp_vmlinux2 .tmp_kallsyms2.o - # step 2a - if [ -n "${KALLSYMS_EXTRA_PASS}" ]; then + # step 3 + size1=$(stat -c "%s" .tmp_kallsyms1.o) + size2=$(stat -c "%s" .tmp_kallsyms2.o) + + if [ $size1 -ne $size2 ] || [ -n "${KALLSYMS_EXTRA_PASS}" ]; then kallsymso=.tmp_kallsyms3.o kallsyms_vmlinux=.tmp_vmlinux3