Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 14 Jul 2022 16:15:35 -0700 | Subject | Re: [PATCH] ubsan: disable UBSAN_DIV_ZERO for clang |
| |
On Thu, Jul 14, 2022 at 1:56 PM Nick Desaulniers <ndesaulniers@google.com> wrote: > > 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 implementation.
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 not.
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" instruction.
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
asm_volatile_goto("\n" \ "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 <emulator_cmpxchg_emulated+0x6b3>
where that last "ja 7d1f3" is the branch to the code that then calls __ubsan_handle_load_invalid_value.
But look at that code: it's literally
sete %al mov %al,%r14b cmp $0x1,%r14b
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.
That's silly.
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.
Linus
| |