[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <421c08e1-255b-447b-b5e3-ee6544fbefd2@loongson.cn>
Date: Mon, 10 Nov 2025 09:18:50 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Ard Biesheuvel <ardb@...nel.org>, Huacai Chen <chenhuacai@...nel.org>
Cc: Josh Poimboeuf <jpoimboe@...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
Subject: Re: [PATCH v2] efistub: Only link libstub to final vmlinux
On 2025/10/28 下午9:47, Ard Biesheuvel wrote:
> On Sun, 26 Oct 2025 at 12:20, Huacai Chen <chenhuacai@...nel.org> wrote:
>>
>> On Thu, Oct 23, 2025 at 4:07 PM Ard Biesheuvel <ardb@...nel.org> wrote:
>>>
>>> On Thu, 23 Oct 2025 at 10:01, Huacai Chen <chenhuacai@...nel.org> wrote:
>>>>
>>>> On Thu, Oct 23, 2025 at 2:55 PM Tiezhu Yang <yangtiezhu@...ngson.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@...ngson.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
Powered by blists - more mailing lists