[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

On Fri, 2018-02-09 at 00:16 +0000, David Woodhouse wrote:
> 
> long long foo(void)
> {
>         long long ret;
> 
>         switch(sizeof(ret)) {
>         case 1:
>                 asm ("movb $5, %0" : "=q" (ret));
>                 break;
> 
>         case 2:
>                 asm ("movw $5, %0" : "=r" (ret));
>                 break;
> 
>         case 4:
>                 asm ("movl $5, %0" : "=r" (ret));
>                 break;
> 
>         case 8: // this bit was complex, but OK.
>                 ret = 1;
>         }
>         return ret;
> }
> 
> q.c:8:30: error: invalid output size for constraint '=q'
>                 asm ("movb $5, %0" : "=q" (ret));
> 
> Now looking up what the "q" constraint is, why it's being used for the
> 1-byte version, and why compilation fails for those and not "r" which
> blatantly can't take a 'long long' *either* but Clang seems to cope
> with that one.

It not only "copes" with "=r" but silently emits code where GCC would
(rightly) warn… if GCC ever got to the point of actually *emitting* it:

 $ cat q.c
long long foo(void)
{
	long long ret;
	asm ("movl $5, %0" : "=r" (ret));
	return ret;
}
 $ clang -c -oq.o q.c -m32
 $ gcc -c -oq.o q.c -m32
q.c: In function ‘foo’:
q.c:6:1: warning: unsupported size for integer register
 }
 ^

Would we get away with making "=q" also silently emit wrong code? :)
On the basis that right here and now it wasn't going to emit it
*anyway*; it gets optimised away.

For now I'm just going to attempt to work around it like this in the
kernel, so I can concentrate on the retpoline bits:
 http://david.woodhou.se/clang-percpu-hack.patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5213 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180209/c21ee665/attachment-0001.bin>