[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1907022332000.1802@nanos.tec.linutronix.de>
Date: Tue, 2 Jul 2019 23:58:27 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Nick Desaulniers <ndesaulniers@...gle.com>
cc: Peter Zijlstra <peterz@...radead.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
clang-built-linux <clang-built-linux@...glegroups.com>,
Kees Cook <keescook@...gle.com>,
LKML <linux-kernel@...r.kernel.org>,
Craig Topper <craig.topper@...el.com>,
Alexander Potapenko <glider@...gle.com>,
Bill Wendling <morbo@...gle.com>,
Stephen Hines <srhines@...gle.com>
Subject: Re: objtool warnings in prerelease clang-9
Nick,
On Tue, 2 Jul 2019, Nick Desaulniers wrote:
> TL;DR
> LLVM currently has a bug when unrolling loops containing asm goto and
> we have a fix in hand.
<snip>
>
> Conservatively, we can block loop unrolling when we see asm goto in a loop:
Makes sense in order to make progress.
> This causes objtool to not find any issues in
> arch/x86/kernel/cpu/mtrr/generic.o. I don't observe any duplication
> in the __jump_table section of the resulting .o file. It also cuts
> down the objtool warnings I observe in a defconfig (listed at the
> beginning of the email) from 4 to 2. (platform-quirks.o predates asm
> goto,
It does not have asm goto inside :)
> i915_gem_execbuffer.o is likely a separate bug).
platform-quirks.o:
if (x86_platform.set_legacy_features)
74: 4c 8b 1d 00 00 00 00 mov 0x0(%rip),%r11 # 7b <x86_early_init_platform_quirks+0x7b>
7b: 4d 85 db test %r11,%r11
7e: 0f 85 00 00 00 00 jne 84 <x86_early_init_platform_quirks+0x84>
x86_platform.set_legacy_features();
}
84: c3 retq
That jne jumps to __x86_indirect_thunk_r11, aka. ratpoutine.
No idea why objtool thinks that the instruction at 0x84 is not
reachable. Josh?
Thanks,
tglx
Powered by blists - more mailing lists