Message-ID: <CAAhV-H6A_swQmqpWHp6ryAEvc96CAMOMd2ZGyJEVNMsJfLkz6w@mail.gmail.com>
Date: Thu, 11 Sep 2025 16:28:37 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Tiezhu Yang <yangtiezhu@...ngson.cn>, Peter Zijlstra <peterz@...radead.org>, 
	Nathan Chancellor <nathan@...nel.org>, loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/3] objtool/LoongArch: Fix unreachable instruction
 warnings about EFISTUB

On Thu, Sep 11, 2025 at 11:23 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
>
> On Wed, Sep 10, 2025 at 02:55:20PM +0800, Huacai Chen wrote:
> >
> > On Wed, Sep 10, 2025 at 12:05 AM Josh Poimboeuf <jpoimboe@...nel.org> wrote:
> > > On Tue, Sep 09, 2025 at 12:10:29PM +0800, Huacai Chen wrote:
> > >
> > > Then it can be __HEAD_RODATA, with the "w" removed:
> > >
> > > #define __HEAD_RODATA   .section        ".head.rodata","a"
> > >
> > > > From my point of view, the text section is still the best for HEAD.
> > >
> > > It belongs in a data section for two reasons:
> > >
> > >   1) It's an image header data structure.
> > >
> > >   2) We don't want objtool (or any other tooling) to try to validate it
> > >      or otherwise treat it as text during the build.
> > I'm sorry but I insist on my opinion. :)
> >
> > Yes, there are reasons to put it into a data section, but there are
> > also reasons to put it into a code section.
> >
> > 1) ARM64, RISC-V and LoongArch have the same style (mix code and data
> > in __HEAD), I don't want to do something special.
>
> There's no need for anything special... Fo ARM64 and RISC-V, if their
> head "code" is actually just structured data, that *also* belongs in a
> data section.
>
> And that can get changed if/when they get objtool support.  If not
> before.
>
> > 2) __HEAD is used for nearly all archs, except ARM64, RISC-V and
> > LoongArch, other archs are almost pure code (so they must use a code
> > section). However, the code in __HEAD is usually not like a regular
> > function. In other word, if other archs add objtool support, __HEAD
> > will also probably cause problems.
>
> Hm?  Objtool can handle "non-regular" functions fine.  That's what the
> unwind hints are for.  x86 has that already and it works fine.
>
> What *actually* causes problems for objtool (and the whole point of this
> discussion) is the placing of data in a text section.  I don't
> understand why we're still arguing about whether that's the right thing
> to do.  Not to mention the fact that using objtool as an excuse *not* to
> do it seems completely backwards!
>
> > 3) Many archs put __HEAD between __init_begin and __init_end, which
> > means it is discarded at runtime, stack unwinder is useless for it.
>
> Unwinding can easily (and often does) happen during boot, before init
> memory is freed.
>
> It could even happen in the head code, e.g. in a debugger.  (whether
> that actually works might be a different story.)
>
> But also, keep in mind that objtool has many other features beyond just
> ORC generation.  In the future it would be quite foreseeable for some
> other objtool feature to get confused by this "code" again and spit out
> more warnings.
>
> Similarly, if loongarch eventually switches to using sframe, and the
> binutils assembler learns how to autogenerate sframe with minimal cfi
> directives (a planned feature I believe), it would have the same problem
> trying to decipher this "code".
>
> > So, ignoring .head.text is not just a workaround for LoongArch, it is
> > a proper solution for other archs.
>
> I'm not convinced of that.  I don't think we want to ignore it on x86.
OK, then don't ignore .head.text in objtool. But I also don't want to
change .head.text to .head.data. So Tiezhu please just use unwind
hints (UNWIND_HINT_UNDEFINED) in __HEAD like the earliest version.
Thanks.


Huacai

>
> --
> Josh

Powered by blists - more mailing lists