Messages in this thread | | | Date | Sat, 28 Jan 2023 11:06:34 -0800 | From | "Paul E. McKenney" <> | Subject | Re: objtool warning for next-20221118 |
| |
On Wed, Nov 23, 2022 at 03:06:12PM -0800, Paul E. McKenney wrote: > On Wed, Nov 23, 2022 at 02:32:14PM -0800, Josh Poimboeuf wrote: > > On Wed, Nov 23, 2022 at 11:12:42AM -0800, Paul E. McKenney wrote: > > > On Wed, Nov 23, 2022 at 10:19:41AM -0800, Josh Poimboeuf wrote: > > > > On Wed, Nov 23, 2022 at 09:49:51AM -0800, Paul E. McKenney wrote: > > > > > > > > Perhaps the best way would be to stick a REACHABLE annotation in > > > > > > > > arch_cpu_idle_dead() or something? > > > > > > > > > > > > > > When I apply this on -next, I still get the objtool complaint. > > > > > > > Is there something else I should also be doing? > > > > > > > > > > > > Silly GCC is folding the inline asm. This works (but still doesn't seem > > > > > > like the right approach): > > > > > > > > > > > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > > > > > index 26e8f57c75ad..128e7d78fedf 100644 > > > > > > --- a/arch/x86/kernel/process.c > > > > > > +++ b/arch/x86/kernel/process.c > > > > > > @@ -702,7 +702,7 @@ static void (*x86_idle)(void); > > > > > > #ifndef CONFIG_SMP > > > > > > static inline void play_dead(void) > > > > > > { > > > > > > - BUG(); > > > > > > + _BUG_FLAGS(ASM_UD2, 0, ASM_REACHABLE); > > > > > > } > > > > > > #endif > > > > > > > > > > I tried this, and still get: > > > > > > > > > > vmlinux.o: warning: objtool: do_idle+0x156: unreachable instruction > > > > > > > > > > Maybe my gcc is haunted? > > > > > > > > Weird, it worked for me. I have > > > > > > > > gcc version 12.2.1 20220819 (Red Hat 12.2.1-2) (GCC) > > > > > > Me, I have these, so quite a bit older: > > > > > > gcc version 8.5.0 20210514 (Red Hat 8.5.0-15) (GCC) > > > gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1) > > > > > > > and I can't really fathom why that wouldn't work. Maybe it's a > > > > different issue? The "unreachable instruction" warning is limited to > > > > one, so when a first warning gets fixed, a second warning might suddenly > > > > become visible. > > > > > > > > Can you attach arch/x86/kernel/process.o? > > > > > > Attached! > > > > Hm, for whatever reason, that .o file is indeed missing the reachable > > annotation. <scratches head> > > There are at least three definitions. Might I be getting the wrong one? > > I have CONFIG_DEBUG_BUGVERBOSE=y and CONFIG_GENERIC_BUG=y, so I would > expect to be using the first one: > > #define _BUG_FLAGS(ins, flags, extra) \ > do { \ > asm_inline volatile("1:\t" ins "\n" \ > ".pushsection __bug_table,\"aw\"\n" \ > "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n" \ > "\t" __BUG_REL(%c0) "\t# bug_entry::file\n" \ > "\t.word %c1" "\t# bug_entry::line\n" \ > "\t.word %c2" "\t# bug_entry::flags\n" \ > "\t.org 2b+%c3\n" \ > ".popsection\n" \ > extra \ > : : "i" (__FILE__), "i" (__LINE__), \ > "i" (flags), \ > "i" (sizeof(struct bug_entry))); \ > } while (0) > > > I confirmed the patch also fixes the warning with: > > > > gcc version 8.5.0 20210514 (Red Hat 8.5.0-10) (GCC) > > > > No idea why it's not working for you... but maybe it doesn't matter as > > I'm still thinking we should go with a different approach. > > OK, then I will await your update.
Sorry to be a nag, but I am still seeing this. Not a huge problem because I now filter it out so that it does not get in the way of other bugs, but I figured that I should follow up.
Thanx, Paul
| |