> -----Original Message-----
> From: Segher Boessenkool <seg...@kernel.crashing.org>
> Sent: 10 September 2020 16:21
> To: David Laight <david.lai...@aculab.com>
> Cc: 'Christophe Leroy' <christophe.le...@csgroup.eu>; 'Linus Torvalds'
> <torvalds@linux-
> foundation.org>; linux-arch <linux-a...@vger.kernel.org>; Kees Cook
> <keesc...@chromium.org>; the
> arch/x86 maintainers <x...@kernel.org>; Nick Desaulniers
> <ndesaulni...@google.com>; Linux Kernel
> Mailing List <linux-ker...@vger.kernel.org>; Alexey Dobriyan
> <adobri...@gmail.com>; Luis Chamberlain
> <mcg...@kernel.org>; Al Viro <v...@zeniv.linux.org.uk>; linux-fsdevel
> <linux-fsde...@vger.kernel.org>;
> linuxppc-dev <linuxppc-dev@lists.ozlabs.org>; Christoph Hellwig <h...@lst.de>
> Subject: Re: remove the last set_fs() in common code, and remove it for x86
> and powerpc v3
>
> On Thu, Sep 10, 2020 at 12:26:53PM +0000, David Laight wrote:
> > Actually this is pretty sound:
> > __label__ label;
> > register int eax asm ("eax");
> > // Ensure eax can't be reloaded from anywhere
> > // In particular it can't be reloaded after the asm goto line
> > asm volatile ("" : "=r" (eax));
>
> This asm is fine. It says it writes the "eax" variable, which lives in
> the eax register *in that asm* (so *not* guaranteed after it!).
>
> > // Provided gcc doesn't save eax here...
> > asm volatile goto ("xxxxx" ::: "eax" : label);
>
> So this is incorrect.
>From the other email:
> It is neither input nor output operand here! Only *then* is a local
> register asm guaranteed to be in the given reg: as input or output to an
> inline asm.
Ok, so adding '"r" (eax)' to the input section helps a bit.
> > // ... and reload the saved value here.
> > // The input value here will be that modified by the 'asm goto'.
> > // Since this modifies eax it can't be moved before the 'asm goto'.
> > asm volatile ("" : "+r" (eax));
> > // So here eax must contain the value set by the "xxxxx" instructions.
>
> No, the register eax will contain the value of the eax variable. In the
> asm; it might well be there before or after the asm as well, but none of
> that is guaranteed.
Perhaps not 'guaranteed', but very unlikely to be wrong.
It doesn't give gcc much scope for not generating the desired code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
