[PATCH v2] efistub: Only link libstub to final vmlinux

Tiezhu Yang yangtiezhu at loongson.cn
Mon Oct 13 00:34:52 PDT 2025


On 2025/10/11 下午11:58, Ard Biesheuvel wrote:
> On Sat, 11 Oct 2025 at 08:01, Huacai Chen <chenhuacai at kernel.org> wrote:...>> Hmmm, I want to know whether this problem is an objtool issue or an
>> efistub issue in essence. If it is an objtool issue, we should fix
>> objtool and don't touch efistub. If it is an efistub issue, then we
>> should modify efistub (but not specific to LoongArch, when RISC-V and
>> ARM64 add objtool they will meet the same issue).
>>
> 
> It is an objtool issue in essence.
> 
> The generated code looks like this
> 
> 9000000001743080: ff b7 fe 57   bl      -332 <__efistub_kernel_entry_address>
> 9000000001743084: 26 03 c0 28   ld.d    $a2, $s2, 0
> 9000000001743088: 87 00 15 00   move    $a3, $a0
> 900000000174308c: 04 04 80 03   ori     $a0, $zero, 1
> 9000000001743090: c5 02 15 00   move    $a1, $fp
> 9000000001743094: e1 00 00 4c   jirl    $ra, $a3, 0
> 
> 9000000001743098 <__efistub_exit_boot_func>:
> 9000000001743098: 63 c0 ff 02   addi.d  $sp, $sp, -16
> 
> There is nothing wrong with this code, given that the indirect call is
> to a __noreturn function, and so the fact that it falls through into
> __efistub_exit_boot_func() is not a problem.
> 
> Even though the compiler does nothing wrong here, it would be nice if
> it would emit some kind of UD or BRK instruction after such a call, if
> only to make the backtrace more reliable. But the code is fine, and
> objtool simply does not have the information it needs to determine
> that the indirect call is of a variety that never returns.
> 
> So I don't mind fixing it in the code, but only for LoongArch, given
> that the problem does not exist on arm64 or RISC-V.

I assume this is the final conclusion, if there is no objection,
I will send patch according to Ard's suggestion and update the
commit message in the next week, the code looks like this:

-----8<-----
diff --git a/drivers/firmware/efi/libstub/loongarch.c 
b/drivers/firmware/efi/libstub/loongarch.c
index 3782d0a187d1..e5991aa9f805 100644
--- a/drivers/firmware/efi/libstub/loongarch.c
+++ b/drivers/firmware/efi/libstub/loongarch.c
@@ -10,8 +10,8 @@
  #include "efistub.h"
  #include "loongarch-stub.h"

-typedef void __noreturn (*kernel_entry_t)(bool efi, unsigned long cmdline,
-                                         unsigned long systab);
+typedef void (*kernel_entry_t)(bool efi, unsigned long cmdline,
+                              unsigned long systab);

  efi_status_t check_platform_features(void)
  {
@@ -81,4 +81,7 @@ efi_status_t efi_boot_kernel(void *handle, 
efi_loaded_image_t *image,

         real_kernel_entry(true, (unsigned long)cmdline_ptr,
                           (unsigned long)efi_system_table);
+
+       /* We should never get here, only to fix the objtool warning */
+       return EFI_LOAD_ERROR;
  }
-----8<-----

Thanks,
Tiezhu




More information about the linux-riscv mailing list