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

[Tiezhu Yang]

On 2025/10/28 下午9:47, Ard Biesheuvel wrote:
> On Sun, 26 Oct 2025 at 12:20, Huacai Chen <chenhuacai at kernel.org> wrote:
>>
>> On Thu, Oct 23, 2025 at 4:07 PM Ard Biesheuvel <ardb at kernel.org> wrote:
>>>
>>> On Thu, 23 Oct 2025 at 10:01, Huacai Chen <chenhuacai at kernel.org> wrote:
>>>>
>>>> On Thu, Oct 23, 2025 at 2:55 PM Tiezhu Yang <yangtiezhu at loongson.cn> wrote:
>>>>>
>>>>> Hi Josh and Ard,
>>>>>
>>>>> On 2025/10/20 下午2:55, Huacai Chen wrote:
>>>>>> On Mon, Oct 20, 2025 at 9:24 AM Tiezhu Yang <yangtiezhu at loongson.cn> wrote:
>>>>>>>
>>>>>>> Hi Josh, Ard and Huacai,
>>>>>>>
>>>>>>> On 2025/10/18 上午1:05, Josh Poimboeuf wrote:
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> But IIUC, the libstub code runs *very* early, and wouldn't show up in a
>>>>>>>> stack trace anyway, because there are no traces of it on the stack once
>>>>>>>> it branches to head.S code (which doesn't save the link register).
>>>>>>>
>>>>>>> Thanks for your discussions.
>>>>>>>
>>>>>>> Are you OK with this current patch?
>>>>>> For me the current patch is just OK.
>>>>>
>>>>> We have discussed this a few times but there is almost no consensus
>>>>> of what should happen next and nothing changes.
>>>>>
>>>>> Could you please give me a clear reply? Then I can make progress for
>>>>> the following series:
>>>>>
>>>>> https://lore.kernel.org/loongarch/20250917112716.24415-1-yangtiezhu@loongson.cn/
>>>> For me, this patch is OK, ignore __efistub_ prefix in objtool is also
>>>> OK [1]. But I cannot accept the way that modifying the efistub part
>>>> only for LoongArch.
>>>>
>>>> Clear enough?
>>>>
>>>
>>> LoongArch is the only architecture which has the problem, so I don't
>>> see a reason to modify other architectures.
>>  From your reply I think the efistub code is completely right, but
>> objtool cannot handle the "noreturn" function pointer. And this patch
>> is a workaround rather than a proper fix (so you don't want to touch
>> other architectures), right?
>>
> 
> That is my reasoning, yes. But Josh is right that it shouldn't make a
> difference in practice, I am just reluctant to make changes to the
> code running on the target to accommodate a flawed build time tool.

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.

Thanks,
Tiezhu