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

[Ard Biesheuvel]

On Mon, 10 Nov 2025 at 08:00, Huacai Chen <chenhuacai at kernel.org> wrote:
>
> On Mon, Nov 10, 2025 at 9:19 AM Tiezhu Yang <yangtiezhu at loongson.cn> wrote:
> >
> > 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.
> Now everyone involved agrees that the efistub code is correct, so the
> proper solution is to fix the compiler. 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?
>

Well, given that objtool cannot even infer this for direct calls (and
needs to built with a list of known noreturn functions in the entire
kernel), I think it is safe to assume that doing this for indirect
calls such as this one is intractable.