Сборка ядра-6.6 для riscv встретила проблему «неопределенная ссылка на __efistub_efi_zboot_entry» ⇐ Linux

[Anonymous]

Я собирал ядро ​​6.6 (исходный код openkylin2.0, последующий дистрибутив Debian) на платформе riscv, я столкнулся с проблемой при сборке с помощью команды dpkg-buildpackage -us -uc, часть журнала сборки приведена ниже:

Код: Выделить всё

riscv64-linux-gnu-ld: arch/riscv/boot/zboot-header.o: in function `.Ldoshdr':
(.head+0x68): undefined reference to `__efistub_efi_zboot_entry'
CC  [M] drivers/net/ethernet/netswift/ngbevf/ngbevf.mod.o
make[4]: *** [/usr/src/packages/tmp/linux-6.6.0/drivers/firmware/efi/libstub/Makefile.zboot:52: arch/riscv/boot/vmlinuz.efi.elf] Error 1
make[3]: *** [/usr/src/packages/tmp/linux-6.6.0/arch/riscv/Makefile:163: vmlinuz.efi] Error 2
make[3]: *** Waiting for unfinished jobs....

соответствующая часть make-файла для этой проблемы находится в драйверах/firmware/efi/libstub/Makefile.zboot:

Код: Выделить всё

ZBOOT_DEPS := $(obj)/zboot-header.o $(objtree)/drivers/firmware/efi/libstub/lib.a

LDFLAGS_vmlinuz.efi.elf := -T $(srctree)/drivers/firmware/efi/libstub/zboot.lds
$(obj)/vmlinuz.efi.elf: $(obj)/vmlinuz.o $(ZBOOT_DEPS) FORCE
$(call if_changed,ld)

В соответствии с этим я также могу воспроизвести эту ошибку вручную:

Код: Выделить всё

 ld -T drivers/firmware/efi/libstub/zboot.lds  -o debian/build/build-generic/arch/riscv/boot/vmlinuz.efi.elf \
debian/build/build-generic/arch/riscv/boot/vmlinuz.o debian/build/build-generic/arch/riscv/boot/zboot-header.o \
debian/build/build-generic/drivers/firmware/efi/libstub/lib.a

ld: debian/build/build-generic/arch/riscv/boot/zboot-header.o: in function `.Ldoshdr':
(.head+0x68): undefined reference to `__efistub_efi_zboot_entry'

Я знаю, что этот дистрибутив имеет собственное настроенное ядро, и я не собираюсь обсуждать это здесь.
Мой вопрос: при поиске по коду ядра __efistub_efi_zboot_entry упоминался только один раз в драйверах/firmware/efi/libstub/zboot-header.S

Код: Выделить всё

.Loptional_header:
.short          .Lpe_opt_magic
.byte           0, 0
.long           _etext - .Lefi_header_end
.long           __data_size
.long           0
.long           __efistub_efi_zboot_entry - .Ldoshdr

и такая метка не была определена в коде ядра, и я считаю, что исходный код (например, debian/ubuntu) не столкнется с такой же проблемой, как эта. Как это произошло, если указана неопределенная функция/метка?
Кстати, я пытался найти патч, в котором эта __efistub_efi_zboot_entry была добавлена ​​в код ядра, патч https://patchew.org/linux/2022091008115 ... ernel.org/. Я хочу найти образец того, как использовать неопределенную метку или способ, которым восходящий код позволяет избежать этой ошибки, но безуспешно.
Какой-нибудь совет по решению этой проблемы с помощью такого метода, как восходящий код?
обновить
в драйверах/firmware/efi/libstub/zboot.c, мы видим efi_zboot_entry был определен, а в драйверах/firmware/efi/libstub/Makefile вот такой контент:

Код: Выделить всё

# part 1
lib-$(CONFIG_EFI_ZBOOT)         += zboot.o $(zboot-obj-y)

lib-$(CONFIG_UNACCEPTED_MEMORY) += unaccepted_memory.o bitmap.o find.o

extra-y                         := $(lib-y)
lib-y                           := $(patsubst %.o,%.stub.o,$(lib-y))
...  ...
# part 2
STUBCOPY_FLAGS-$(CONFIG_RISCV)  += --prefix-alloc-sections=.init \
--prefix-symbols=__efistub_
STUBCOPY_RELOC-$(CONFIG_RISCV)  := R_RISCV_HI20
...  ...
# part 3
$(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,stubcopy)

quiet_cmd_stubcopy = STUBCPY $@
cmd_stubcopy =                                                    \
$(STRIP) --strip-debug -o $@ $&2; \
/bin/false;                                             \
fi;                                                             \
$(OBJCOPY) $(STUBCOPY_FLAGS-y) $< $@

из этих трех частей make-файла мы знаем:

• Код: Выделить всё

  __efistub_efi_zboot_entry

  — это efi_zboot_entry в zboot.c, префикс был добавлен objcopy.
• Поэтому zboot.c должен быть включен в процесс сборки.
• zboot.c не будет включен, если CONFIG_EFI_ZBOOT не установлен или для него установлено значение «n».

Значит, если для параметра CONFIG_EFI_ZBOOT установлено значение «нет», всегда будут возникать проблемы со сборкой? Это похоже на очевидную ОШИБКУ? Я что-то пропустил?

Подробнее здесь: https://stackoverflow.com/questions/797 ... boot-entry