On Thu, May 16, 2019 at 2:21 PM Miguel Ojeda <miguel.ojeda.sandonis@xxxxxxxxx> wrote: > > Hi, > > On Thu, May 16, 2019 at 10:11 PM Ivan Babrou <ivan@xxxxxxxxxxxxxx> wrote: > > > > Hey Miguel, > > > > The first error is during perf build process (make -C tools/perf install): > > > > [17:38:21] In file included from /usr/include/string.h:635, > > [17:38:21] from ui/tui/helpline.c:4: > > [17:38:21] In function 'strncpy', > > [17:38:21] inlined from 'tui_helpline__push' at ui/tui/helpline.c:27:2: > > [17:38:21] /usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error: > > '__builtin_strncpy' specified bound 512 equals destination size > > [-Werror=stringop-truncation] > > [17:38:21] 126 | return __builtin___strncpy_chk (__dest, __src, > > __len, __bos (__dest)); > > [17:38:21] | > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > [17:38:21] cc1: all warnings being treated as errors > > [17:38:21] /cfsetup_build/build/linux-4.19.43/tools/build/Makefile.build:96: > > recipe for target '/cfsetup_build/build/amd64/perf/ui/tui/helpline.o' > > failed > > [17:38:21] mv: cannot stat > > '/cfsetup_build/build/amd64/perf/ui/tui/.helpline.o.tmp': No such file > > or directory > > [17:38:21] make[6]: *** > > [/cfsetup_build/build/amd64/perf/ui/tui/helpline.o] Error 1 > > [17:38:21] make[5]: *** [tui] Error 2 > > [17:38:21] make[4]: *** [ui] Error 2 > > > > I see that stringop-truncation is disabled in toplevel Makefile, but > > not sure if perf is using it. > > Ah, alright -- CC'ing the perf maintainers then in case they want to chime in. > > > If I disable perf build, the next thing is warnings like these: > > > > mm/slub.o: warning: objtool: init_cache_random_seq()+0x36: sibling > > call from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: slab_out_of_memory()+0x3b: sibling call > > from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: slab_pad_check.part.0()+0x7c: sibling > > call from callable instruction with modified stack frame > > mm/slub.o: warning: objtool: check_slab()+0x1c: sibling call from > > callable instruction with modified stack frame > > AFAIK those are non-critical, i.e. stack traces may be wrong (or not), > but it does not mean the generated kernel itself is wrong. CC'ing the > objtool maintainers too. I really like my stack traces definitely correct :) Thanks for looping in the right people. > > After patching that I see: > > > > In file included from /tmp/build/linux-4.19.43/arch/x86/crypto/aes_glue.c:6: > > /tmp/build/linux-4.19.43/include/linux/module.h:133:6: warning: > > 'init_module' specifies less restrictive attribute than its target > > 'aes_init': 'cold' [-Wmissing-attributes] > > 133 | int init_module(void) __attribute__((alias(#initfn))); > > | ^~~~~~~~~~~ > > /tmp/build/linux-4.19.43/arch/x86/crypto/aes_glue.c:64:1: note: in > > expansion of macro 'module_init' > > 64 | module_init(aes_init); > > | ^~~~~~~~~~~ > > /tmp/build/linux-4.19.43/arch/x86/crypto/aes_glue.c:54:19: note: > > 'init_module' target declared here > > 54 | static int __init aes_init(void) > > | ^~~~~~~~ > > Ditto here, those can be ignored too (unless something has changed in > GCC that I am not aware of). > > > I'm not really comfortable with all the warnings, so I stopped the > > build, maybe it indeed compiles through the end. > > It does (on my GCC 9.1.1 compiled from source). > > I am not sure what is the policy on backporting (someone from the > stable team can probably answer that; Greg?), but note that this > kernel (and 4.20 and 5.0) was released before GCC 9 did -- and some > (all?) of this was cleaned up before GCC 9 itself released, so we were > ahead of it :-) > > Cheers, > Miguel
