clang validates extended assembly constraints even when -fno-integrated-as is set

[nickdesaulniers]

upstream bug: https://llvm.org/pr33587

TL;DR

Clang will validate extended inline assembly, even if the code gets compiled out. This conflicts with some macros that involve switching on the sizeof a type.

The validity check is done early in the front-end partly because the backend (as it stands today) cannot handle inline-asm instructions that have constraints that are not valid for the input or output operands

[dileks]

With patches from <tip.git#locking/core> I was able to build a Linux v4.18-rc6 kernel.

These are the relevant patches:
locking/atomics: Instrument cmpxchg_double*()
locking/atomics: Instrument xchg()
locking/atomics: Simplify cmpxchg() instrumentation
locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation

Unfortunately, the generated linux-kernel does not boot on bare due to issue #7 "__builtin_constant_p() does not work in deep inline functions". I have set CONFIG_HARDENED_USERCOPY=y.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=locking/core

[nickdesaulniers]

Once they land upstream, I can send them to stable (we're going to support LTS branches back to 4.4, so 4.17, 4.14, 4.9, and 4.4).

[dileks]

The patches are now in upstream (will be in v4.19-rc1).

[nickdesaulniers]

Thanks for the heads up @dileks ! 🍰 Let me see how much work these are to backport to stable (seems like there weren't marked for inclusion into stable).

commit 4d2b25f ("locking/atomics: Instrument cmpxchg_double*()")
commit f9881cc ("locking/atomics: Instrument xchg()")
commit df79ed2 ("locking/atomics: Simplify cmpxchg() instrumentation")
commit 00d5551 ("locking/atomics/x86: Reduce arch_cmpxchg64*() instrumentation")

[dileks]

The backport work is worth for 4.17 and 4.18 as these have:
b06ed71 locking/atomic, asm-generic: Add asm-generic/atomic-instrumented.h

$ git describe --contains b06ed71a624b
v4.17-rc1~180^2~9

[nickdesaulniers]

This is an issue for _static_cpu_has, arch_static_branch, arch_static_branch_jump, static_key_false, static_key_true, and perf_sw_event (at least for x86_64). The first 3 use the i inline asm constraint with __attribute__((always_inline)) which ends up producing functions that are literally invalid until inlining occurs, meaning they can only compile with gcc -O2 and will fail with gcc -O0. Clang highlights this and refuses to compile these functions, unless I change them and their __always_inline callsites to all be macros.