[llvm-dev] retpoline mitigation and 6.0

Guenter Roeck via llvm-dev llvm-dev at lists.llvm.org
Wed Feb 7 10:11:25 PST 2018

On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote:
> On Wed, 2018-02-07 at 06:20 +0000, Chandler Carruth wrote:
> > I've landed the patch in r324449.
> > 
> > Before we merge this into two different Clang release branches and
> > almost immediately release one of them, I would really like someone
> > to confirm that this patch works well with the Linux kernel. David,
> > if you're up for that, it would be great. Alternatively, Guenter or
> > someone else here can help.
> Hm, please could we also have the %V asm constraint modifier? That
> allows us to emit calls to the thunks from inline asm using the
> register that the compiler chose for us:
>  asm volatile ("call __x86_indirect_thunk_%V[thunk_target]" : :
> 		[thunk_target] "r" (the_function)); 
> Other than that, I get the following errors with LLVM+Clang master, and
> my tree at
> http://git.infradead.org/users/dwmw2/linux-retpoline.git/shortlog/refs/heads/ibpb

I tried ToT clang with Linux upstream as well as chromeos-4.14,
with 'defconfig'. I don't see any errors when building x86_64.
Lots and lots of warnings, though.

When trying to build for ARCH=i386, I get

arch/x86/events/intel/../perf_event.h:767:21: error:
	invalid output size for constraint '=q'

and a clang crash when compiling drivers/gpu/drm/i915/i915_perf.c.

#0 0x0000000001ee982a llvm::sys::PrintStackTrace(llvm::raw_ostream&)
#1 0x0000000001ee7a7e llvm::sys::RunSignalHandlers()
#2 0x0000000001ee7bba SignalHandler(int)
#3 0x00002b7bcb485330 __restore_rt
#4 0x0000000002727b04

Linux: v4.15-11704-ga2e5790d8416
clang version 7.0.0 (https://git.llvm.org/git/clang.git/ 848874aed95a913fb45f363120500cebfe54e2ef) (https://git.llvm.org/git/llvm.git/3afd566557f3616881505db0d69f5d19bf55ae14)

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

which are both not available in the upstream kernel.

For x86_64, code generation appears to be as expected.
Next, I'll try to apply the patch on top of the Google toolchain
(based on llvm 6.0) and run it on a real system.


More information about the llvm-dev mailing list