On Tue, Jul 16, 2019 at 4:17 PM Josh Poimboeuf <jpoim...@redhat.com> wrote: > > On Mon, Jul 15, 2019 at 02:45:39PM -0700, Nick Desaulniers wrote: > > For a defconfig, that's the only issue I see. > > (Note that I just landed https://reviews.llvm.org/rL366130 for fixing > > up bugs from loop unrolling loops containing asm goto with Clang, so > > anyone else testing w/ clang will see fewer objtool warnings with that > > patch applied. A follow up is being worked on in > > https://reviews.llvm.org/D64101). > > > > For allmodconfig: > > arch/x86/ia32/ia32_signal.o: warning: objtool: > > ia32_setup_rt_frame()+0x247: call to memset() with UACCESS enabled > > mm/kasan/common.o: warning: objtool: kasan_report()+0x52: call to > > __stack_chk_fail() with UACCESS enabled > > arch/x86/kernel/signal.o: warning: objtool: > > x32_setup_rt_frame()+0x255: call to memset() with UACCESS enabled > > arch/x86/kernel/signal.o: warning: objtool: __setup_rt_frame()+0x254: > > call to memset() with UACCESS enabled > > drivers/ata/sata_dwc_460ex.o: warning: objtool: > > sata_dwc_bmdma_start_by_tag()+0x3a0: can't find switch jump table > > lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x88: > > call to memset() with UACCESS enabled > > lib/ubsan.o: warning: objtool: ubsan_type_mismatch_common()+0x610: > > call to __stack_chk_fail() with UACCESS enabled > > lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x88: > > call to memset() with UACCESS enabled > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.o: warning: objtool: > > .altinstr_replacement+0x56: redundant UACCESS disable > > > > Without your series, I see them anyways, so I don't consider them > > regressions added by this series. Let's follow up on these maybe in a > > new thread? (Shall I send you these object files?) > > Yes, maybe open a new thread and be sure to copy PeterZ. He loves those > warnings ;-) Object files are definitely needed. > > > So for the series: > > Tested-by: Nick Desaulniers <ndesaulni...@google.com> > > Thanks! > > > > > > > > > > > I haven't dug into it yet. > > > > > > > > 2) There's also an issue in clang where a large switch table had a bunch > > > > of unused (bad) entries. It's not a code correctness issue, but > > > > hopefully it can get fixed in clang anyway. See patch 20/22 for more > > > > details. > > > > Thanks for the report, let's follow up on steps for me to reproduce. > > Just to clarify, there are two clang issues. Both of them were reported > originally by Arnd, IIRC. > > 1) The one described above and in patch 20, where the switch table is > mostly unused entries. Not a real bug, but it's a bit sloppy and > wasteful, and objtool doesn't know how to interpret it.
Thanks for the concise reports. Will follow up on these in: https://github.com/ClangBuiltLinux/linux/issues/611 > > 2) The bug with the noreturn call site having a different stack size > depending on which code path was taken. and: https://github.com/ClangBuiltLinux/linux/issues/612 -- Thanks, ~Nick Desaulniers
