Re: [PATCH v5] x86: use builtins to read eflags
From: Florian Weimer
Date: Thu Mar 17 2022 - 16:13:58 EST
* Linus Torvalds:
> You can actually operate on EFLAGS at multiple granularities.
>
> - normal pushf/popf. Don't do it unless you are doing system software.
There's one exception: PUSHF/twiddle/POPF/PUSHF/compare is the
recommended sequence to detect CPUID support on i386 (in userspace and
elsewhere).
> - you can use lahf/sahc to load/store only the arithmetic flags
> into/from AH. Deprecated, and going away, but historically supported.
And these instructions were missing from the original long mode, but
they were added back.
> Yes, yes, that complete mental breakdown with pushf/popf did get
> fixed, but it really makes me very wary of thinking that we should
> ever use a built-in that compiler writers really fundamentally got so
> wrong before.
>
> What would make me think that you'd get it right now? In user space,
> you'll basically never actually see the whole system flags issues, so
> your test-cases would never work or be very contrieved. You'd have to
> really work at it to see the problems.
I think as the result of the nature of that kind of bug it does not
matter whether you use a compiler builtin to access the flags (to put
their combined value into a general-purpose register).
GCC doesn't have barriers in the built-ins (if we are talking about
__builtin_ia32_readeflags_u64 and __builtin_ia32_writeeflags_u64). I
expect they are actually pretty useless, and were merely added for
completeness of the intrinsics headers.
It's not that you can write
unsigned a, b, c;
// …
c = a + b;
and examine __builtin_ia32_readeflags_u64() to see if there was an
overflow. Neither GCC nor Clang model the EFLAGS register and
arithmetic expression side effects to make this possible.
Thanks,
Florian