Message-ID: <fc4fa66f-15a0-ebe3-0a27-f3f38b03bbdb@loongson.cn>
Date: Sun, 23 Nov 2025 11:37:14 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: Will Deacon <will@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Catalin Marinas <catalin.marinas@....com>, Paul Walmsley <pjw@...nel.org>,
 Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
 "Madhavan T. Venkataraman" <madvenka@...ux.microsoft.com>,
 Ard Biesheuvel <ardb@...nel.org>, loongarch@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-riscv@...ts.infradead.org,
 linux-efi@...r.kernel.org, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, Nathan Chancellor <nathan@...nel.org>
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux

On 11/23/25 10:29, Huacai Chen wrote:
> On Sat, Nov 22, 2025 at 7:04 PM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>>
>> Cc: Nathan Chancellor <nathan@...nel.org>
>>
>> Hi all,
>>
>> On 11/21/25 22:36, Huacai Chen wrote:
>>> On Mon, Nov 17, 2025 at 7:33 PM Will Deacon <will@...nel.org> wrote:
>>>>
>>>> On Sat, Nov 15, 2025 at 11:16:42AM +0800, Huacai Chen wrote:
>>>>> On Wed, Nov 12, 2025 at 2:00 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>>>>>>
>>>>>> On Mon, Nov 10, 2025 at 03:00:00PM +0800, Huacai Chen wrote:
>>>>>>> On Mon, Nov 10, 2025 at 9:19 AM Tiezhu Yang <yangtiezhu@...ngson.cn> wrote:
>>>>>>>> If I understand correctly, I should modify this patch to remove the
>>>>>>>> changes of arm and riscv for now, do the changes only when there is
>>>>>>>> a real problem or requirement some day, right? If no more comments,
>>>>>>>> I will send v3 later.
>>>>>>>
>>>>>>> Now everyone involved agrees that the efistub code is correct, so the
>>>>>>> proper solution is to fix the compiler.
>>>>>>
>>>>>> Hm?  I don't see how it's a compiler bug.  It's really just an objtool
>>>>>> limitation.
>>>>>>
>>>>>>> Changing efistub code and changing objtool (ignore __efistub prefix)
>>>>>>> are both workarounds, but I think changing objtool is a little more
>>>>>>> reasonable. Maybe Josh has different ideas?
>>>>>>
>>>>>> I thought the conversation had converged on what Tiezhu mentioned above,
>>>>>> which is to skip objtool on libstub for loongarch, but leave the other
>>>>>> arches alone.  That way objtool behavior is consistent between loongarch
>>>>>> and x86, and objtool doesn't need to ignore any prefixes.
>>>>>>
>>>>>> So basically, the v2 patch minus the arm64/riscv changes.
>>>>>
>>>>> Hi, ARM64 and RISC-V maintainers,
>>>>>
>>>>> Would you mind that this patch modifies the three architectures
>>>>> together (they are exactly the same style now)?
>>>>>
>>>>> Madhavan is the author of ARM64's objtool, I think your opinion is
>>>>> also very important.
>>>>
>>>> arm64 doesn't (yet) use objtool.
>>>>
>>>> I defer to Ard on anything relating to the arm64 efistub. Reading the
>>>> start of this thread, it doesn't look like he's convinced and I'm not
>>>> surprised if it's purely an issue with objtool.
>>> OK, I know, but I have a concern.
>>>
>>> Ard said that he is reluctant to make changes to accommodate a flawed
>>> build time tool and there may be regression risk.
>>>
>>> So, I'm also reluctant and don't want LoongArch to meet regression
>>> risk. If one day LoongArch has a regression, we probably need another
>>> workaround to "fix" this workaround. But if these three architectures
>>> change in the same way, we may have a chance to solve some fundamental
>>> problems...
>>
>> IIUC, Josh do not like to ignore these EFISTUB functions in
>> validate_branch() of objtool, Huacai do not like to only link
>> libstub to vmlinux only for LoongArch.
>>
>> It seems that there is only one way to fix or workaround this
>> problem, remove the attribute __noreturn for real_kernel_entry()
>> and then make efi_boot_kernel() ends with a return instruction [1]
>> or an unconditional jump instruction [2] that only touches
>> drivers/firmware/efi/libstub/loongarch.c.
>>
>> Since this is a issue only for LoongArch by now, what do you
>> think of this minimal change only for LoongArch libstub code?
>> Using "return EFI_LOAD_ERROR" [1] or "while (1)" [2]?
>>
>> Maybe this is the simple and direct way for this special issue
>> only on LoongArch so far. If not, any other suggestions?
>>
>> On the other hand, is it possible to add KBUILD_VMLINUX_LIBS_FINAL
>> and then use it only for LoongArch first [3]? Any potential risks?
>>
>> What is the next step?
> Is it possible to improve objtool that can handle indirect __noreturn functions?
> Is it possible to improve objtool that can handle
> OBJECT_FILES_NON_STANDARD event LTO is enabled?
> Is it possible to improve objtool that only ignore __efistub prefix
> for LoongArch?

I think a new arch_is_efistub() can be added in objtool
to handle this issue only for LoongArch, something like:

bool arch_is_retpoline(struct symbol *sym);
bool arch_is_rethunk(struct symbol *sym);
bool arch_is_embedded_insn(struct symbol *sym);

This is valid for LoongArch and will not affect x86,
arm64 and riscv can implement it some day.

The code looks like:

tools/objtool/include/objtool/arch.h:
bool arch_is_efistub(struct symbol *sym);

tools/objtool/check.c:
__weak bool arch_is_efistub(struct symbol *sym)
{
	return false;
}

tools/objtool/arch/loongarch/decode.c:
bool arch_is_efistub(struct symbol *sym)
{
	return !strncmp(func->name, "__efistub_", 10));
}

tools/objtool/check.c:
static int validate_branch()
{
...
			if (arch_is_efistub(func))
				return 0;

			if (file->ignore_unreachables)
				return 0;

			WARN("%s() falls through to next function %s()",
			     func->name, insn_func(insn)->name);
			func->warned = 1;

			return 1;
...
}

Let us wait for Josh's opinion.

Thanks,
Tiezhu

Powered by blists - more mailing lists