Re: [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@xxxxxxxxxx> wrote:
> > On Thu, Oct 23, 2025 at 4:07 PM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
> > > On Thu, 23 Oct 2025 at 10:01, Huacai Chen <chenhuacai@xxxxxxxxxx> wrote:
> > > > On Thu, Oct 23, 2025 at 2:55 PM Tiezhu Yang <yangtiezhu@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxx/
> > > > 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