[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANiq72=fsL5m2_e+bNovFCHy3=YVf53EKGtGE_sWvsAD=ONHuQ@mail.gmail.com>
Date: Thu, 16 May 2019 23:20:54 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Ivan Babrou <ivan@...udflare.com>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Greg KH <gregkh@...uxfoundation.org>
Cc: Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
kernel-team <kernel-team@...udflare.com>
Subject: Re: Linux 4.19 and GCC 9
Hi,
On Thu, May 16, 2019 at 10:11 PM Ivan Babrou <ivan@...udflare.com> 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.
> 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
Powered by blists - more mailing lists