[llvm-dev] retpoline mitigation and 6.0
David Woodhouse via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 7 13:55:38 PST 2018
On Wed, 2018-02-07 at 13:16 -0800, Guenter Roeck wrote:
> Here are my exact versions:
> llvm: 3afd566557f3 ("AMDGPU: Add 32-bit constant address space")
> clang: 848874aed95a ("[clang-format] Fix ObjC message arguments formatting.")
OK, mine are slightly newer than that now, but I now get a working 64-
bit defconfig build. It'll still break with any PV guest support
enabled because we need %V asm constraint modifiers.
> make CC=clang defconfig
> make CC=clang -j80
> The build is a bit noisy right now due to 66f793099a63 ("x86/retpoline: Avoid
> retpolines for built-in __init functions"), since clang doesn't understand
I fixed that (well, worked around it) in my tree.
> > > I can disable the i915 driver, but the "invalid output size for
> > > constraint '=q'" happens all over the place. Ultimately this means
> > > that I can not really test a 32-bit build, though it would not build
> > > anyway because it requires the following symbols
> > >
> > > U __x86_indirect_thunk_esp
> > > U __x86_indirect_thunk
> > The latter I can live with, as discussed, for 32-bit only. We don't
> > care about CET compatibility there, so I'm OK to implement the bare
> > ret-equivalent __x86_indirect_thunk.
> > The former... wtf? Can you show me the code that actually *calls* that.
> > I am having difficulty imagining any situation in which that's sane.
> Turns out this was PBKAC. That was with chromeos-4.14, which does not yet
> include the upstream patch removing __x86_indirect_thunk_esp. I don't
> see it with ToT. The "U" was from ./arch/x86/lib/lib-ksyms.o, meaning it
> was internally generated. Sorry for the noise.
OK... which __x86_indirect_thunk* symbols *are* being used by Clang in
32-bit mode? I've added __x86_indirect_thunk for 32-bit now, and if
that's *all* the Clang is using then I'll possibly switch GCC into that
Can you take care of filing the tickets for %V0 and "=q"
and attribute__((indirect_branch("keep"))) please? With those fixed, I
think we should be OK again.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5213 bytes
Desc: not available
More information about the llvm-dev