Re: [PATCH] ubsan: disable UBSAN_DIV_ZERO for clang
From: Linus Torvalds
Date: Thu Jul 14 2022 - 19:16:01 EST
On Thu, Jul 14, 2022 at 1:56 PM Nick Desaulniers
> Building with UBSAN_DIV_ZERO with clang produces numerous fallthrough
> warnings from objtool.
Ok, with this applied, things are better.
There are still the "__ubsan_handle_load_invalid_value() with UACCESS
enabled" messages, but those are misfeatures of the kvm cmpxchg
I'm not entirely sure why the clang build warns but gcc doesn't, but I
*think* it's because clang is just being silly. It *looks* like it
checks that a "bool" has a value range of 0/1, and will complain if
And the reason I say that's silly is that if I read it correctly, then
that value has literally been generated by clang itself, using "setz"
It's the __try_cmpxchg_user_asm() macro, and with clang-14 I have it's
that CONFIG_CC_HAS_ASM_GOTO_TIED_OUTPUT case, and the C code uses
inline asm and does
"1: " LOCK_PREFIX "cmpxchg"itype" %[new], %[ptr]\n"\
_ASM_EXTABLE_UA(1b, %l[label]) \
: CC_OUT(z) (success), \
where that CC_OUT() in this case turns into
# define CC_OUT(c) "=@cc" #c
and clang generates this code for it:
7d01e: f0 48 0f b1 4d 00 lock cmpxchg %rcx,0x0(%rbp)
7d024: 49 89 c5 mov %rax,%r13
7d027: 0f 94 c0 sete %al
7d02a: 41 88 c6 mov %al,%r14b
7d02d: bf 02 00 00 00 mov $0x2,%edi
7d032: 44 89 f6 mov %r14d,%esi
7d035: e8 00 00 00 00 call __sanitizer_cov_trace_const_cmp1
7d03a: 41 80 fe 01 cmp $0x1,%r14b
7d03e: 0f 87 af 01 00 00 ja 7d1f3
where that last "ja 7d1f3" is the branch to the code that then
But look at that code: it's literally
where clang has generated that "sete itself, and then it verifies that
the result is "<= 1".
IOW, clang seems to be literally just checking that the "sete"
instruction works right.
Maybe I'm misreading this, but I think the reason the clang build
complains, but the gcc build does not, is simply because gcc isn't
doing crazy checks of how the CPU works.
Some mis-feature of the "asm with flag output" code, where clang
doesn't understand that it generated that code itself, and the "setcc"
instruction always returns 0/1?
The old issue with "memcpy/memset() leaves .noinstr.text section"
because clang has generated out-of-line functions for trivial copies
also remains, but whatever.