[llvm-dev] retpoline mitigation and 6.0

[David Woodhouse via llvm-dev]

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>