llvm dev - Feb 2018 - retpoline mitigation and 6.0

On Fri, 2018-02-09 at 00:09 +0000, Chandler Carruth
wrote:
> > 
> > For 64-bit it's fine. For 32-bit we *think* the retpoline bits are
OK
> > but it doesn't build for other reasons on 32-bit. But that
isn't new
> > breakage — 5.0 has the same problem with the latest kernel. I'll
see if
> > we can work around that in the kernel, instead of relying on certain
> > inline asms getting optimised away before the compiler ever notices
> > that they're bogus.
>
> Cool, let us know if we can help here, but this at least tells us
> that we're in pretty good shape to start backporting everything.
Test case (build with -m32):


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.

-------------- 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/860e866e/attachment.bin>

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>

On Fri, 2018-02-09 at 01:18 +0000, David Woodhouse
wrote:
> 
> 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
32-bit doesn't boot. Built without CONFIG_RETPOLINE and with Clang 5.0
(and the above patch) it does. I'm rebuilding a Release build of
llvm/clang so that experimental kernel builds hopefully take less than
an hour, and will prod further in the morning.
-------------- 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/bf3fe0ad/attachment.bin>