Hi,
On Thu, May 16, 2019 at 10:11 PM Ivan Babrou <[email protected]> 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
On Thu, May 16, 2019 at 11:20:54PM +0200, Miguel Ojeda wrote:
> > 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 don't think I recognize those warnings. Do you also see them in the
upstream kernel?
--
Josh
We are building the upstream kernel. There are a few patches, but
nothing related to objtool.
Unless you mean mainline/stable by upstream, I haven't tried that. We
stick to LTS.
On Thu, May 16, 2019 at 7:04 PM Josh Poimboeuf <[email protected]> wrote:
>
> On Thu, May 16, 2019 at 11:20:54PM +0200, Miguel Ojeda wrote:
> > > 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 don't think I recognize those warnings. Do you also see them in the
> upstream kernel?
>
> --
> Josh
On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> We are building the upstream kernel. There are a few patches, but
> nothing related to objtool.
>
> Unless you mean mainline/stable by upstream, I haven't tried that. We
> stick to LTS.
Please work and all of these issues fixed up in Linus's tree and then I
will be glad to take the fixed into the stable releases.
thanks,
greg k-h
On Fri, May 17, 2019 at 07:09:31AM +0200, Greg KH wrote:
> On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> > We are building the upstream kernel. There are a few patches, but
> > nothing related to objtool.
> >
> > Unless you mean mainline/stable by upstream, I haven't tried that. We
> > stick to LTS.
>
> Please work and all of these issues fixed up in Linus's tree and then I
> will be glad to take the fixed into the stable releases.
Right; if there is anything you can reproduce on linus.git I'll happily
have a look. If it doesn't reproduce all you have to do is find the
patches that make it work and ask Greg.
On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
>
> On Fri, May 17, 2019 at 07:09:31AM +0200, Greg KH wrote:
> > On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> > > We are building the upstream kernel. There are a few patches, but
> > > nothing related to objtool.
> > >
> > > Unless you mean mainline/stable by upstream, I haven't tried that. We
> > > stick to LTS.
> >
> > Please work and all of these issues fixed up in Linus's tree and then I
> > will be glad to take the fixed into the stable releases.
>
> Right; if there is anything you can reproduce on linus.git I'll happily
> have a look. If it doesn't reproduce all you have to do is find the
> patches that make it work and ask Greg.
Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
Cheers,
Miguel
On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
> >
> > On Fri, May 17, 2019 at 07:09:31AM +0200, Greg KH wrote:
> > > On Thu, May 16, 2019 at 08:14:25PM -0700, Ivan Babrou wrote:
> > > > We are building the upstream kernel. There are a few patches, but
> > > > nothing related to objtool.
> > > >
> > > > Unless you mean mainline/stable by upstream, I haven't tried that. We
> > > > stick to LTS.
> > >
> > > Please work and all of these issues fixed up in Linus's tree and then I
> > > will be glad to take the fixed into the stable releases.
> >
> > Right; if there is anything you can reproduce on linus.git I'll happily
> > have a look. If it doesn't reproduce all you have to do is find the
> > patches that make it work and ask Greg.
>
> Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
Great! Care to find the patches that did that work and send me the git
commit ids so that I can queue them up? I don't have gcc9 here yet on
my systems, so I can not test for this.
thanks,
greg k-h
On Fri, May 17, 2019 at 10:51 AM Greg KH <[email protected]> wrote:
>
> On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
> > >
> > > Right; if there is anything you can reproduce on linus.git I'll happily
> > > have a look. If it doesn't reproduce all you have to do is find the
> > > patches that make it work and ask Greg.
> >
> > Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
>
> Great! Care to find the patches that did that work and send me the git
> commit ids so that I can queue them up? I don't have gcc9 here yet on
> my systems, so I can not test for this.
I am unsure about the perf and the objtools parts (Peter/Josh?), but
about the -Wmissing-attributes I cleaned, they were these:
a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
init/cleanup_module")
c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >= 9)")
ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
aliases as __pure")
Cheers,
Miguel
On Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda wrote:
> On Fri, May 17, 2019 at 10:51 AM Greg KH <[email protected]> wrote:
> >
> > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
> > > >
> > > > Right; if there is anything you can reproduce on linus.git I'll happily
> > > > have a look. If it doesn't reproduce all you have to do is find the
> > > > patches that make it work and ask Greg.
> > >
> > > Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
> >
> > Great! Care to find the patches that did that work and send me the git
> > commit ids so that I can queue them up? I don't have gcc9 here yet on
> > my systems, so I can not test for this.
>
> I am unsure about the perf and the objtools parts (Peter/Josh?), but
> about the -Wmissing-attributes I cleaned, they were these:
>
> a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
> init/cleanup_module")
> c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >= 9)")
> ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
> aliases as __pure")
This last patch is not needed, as that only resolves something that
showed in in 4.20.
thanks,
greg k-h
Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> On Fri, May 17, 2019 at 10:51 AM Greg KH <[email protected]> wrote:
> >
> > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
> > > >
> > > > Right; if there is anything you can reproduce on linus.git I'll happily
> > > > have a look. If it doesn't reproduce all you have to do is find the
> > > > patches that make it work and ask Greg.
> > >
> > > Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
> >
> > Great! Care to find the patches that did that work and send me the git
> > commit ids so that I can queue them up? I don't have gcc9 here yet on
> > my systems, so I can not test for this.
>
> I am unsure about the perf and the objtools parts (Peter/Josh?), but
I'm not noticing these while building upstream perf with gcc 9.1.1 on at
least fedora:30.
33 fedora:30 : Ok gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
> about the -Wmissing-attributes I cleaned, they were these:
> a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
> init/cleanup_module")
> c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >= 9)")
> ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
> aliases as __pure")
>
> Cheers,
> Miguel
--
- Arnaldo
On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
<[email protected]> wrote:
>
> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> > On Fri, May 17, 2019 at 10:51 AM Greg KH <[email protected]> wrote:
> > >
> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra <[email protected]> wrote:
> > > > >
> > > > > Right; if there is anything you can reproduce on linus.git I'll happily
> > > > > have a look. If it doesn't reproduce all you have to do is find the
> > > > > patches that make it work and ask Greg.
> > > >
> > > > Just to clarify: Linus' master is clean of these issues with GCC 9.1.1.
> > >
> > > Great! Care to find the patches that did that work and send me the git
> > > commit ids so that I can queue them up? I don't have gcc9 here yet on
> > > my systems, so I can not test for this.
> >
> > I am unsure about the perf and the objtools parts (Peter/Josh?), but
>
> I'm not noticing these while building upstream perf with gcc 9.1.1 on at
> least fedora:30.
>
> 33 fedora:30 : Ok gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
I've tried to replicate this in fedora:30 docker container and it's there:
[root@linuxkit-025000000001 perf]# gcc --version
gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
[root@linuxkit-025000000001 perf]# pwd
/tmp/linux-4.19.44/tools/perf
[root@linuxkit-025000000001 perf]# make -j1
...
trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_kvm_cmd’:
trace/beauty/ioctl.c:85:82: error: array subscript [-2147483648, -1]
is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
85 | if (nr < strarray__kvm_ioctl_cmds.nr_entries &&
strarray__kvm_ioctl_cmds.entries[nr] != NULL)
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
In file included from trace/beauty/ioctl.c:82:
/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/kvm_ioctl_array.c:1:20:
note: while referencing ‘kvm_ioctl_cmds’
1 | static const char *kvm_ioctl_cmds[] = {
| ^~~~~~~~~~~~~~
In file included from /usr/include/string.h:494,
from util/debug.h:7,
from builtin-help.c:15:
In function ‘strncpy’,
inlined from ‘add_man_viewer’ at builtin-help.c:192:2,
inlined from ‘perf_help_config’ at builtin-help.c:284:3:
/usr/include/bits/string_fortified.h:106:10: error:
‘__builtin_strncpy’ output truncated before terminating nul copying as
many bytes from a string as its length [-Werror=stringop-truncation]
106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos (__dest));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
builtin-help.c: In function ‘perf_help_config’:
builtin-help.c:187:15: note: length computed here
187 | size_t len = strlen(name);
| ^~~~~~~~~~~~
trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_perf_cmd’:
trace/beauty/ioctl.c:109:84: error: array subscript [-2147483648, -1]
is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
109 | if (nr < strarray__perf_ioctl_cmds.nr_entries &&
strarray__perf_ioctl_cmds.entries[nr] != NULL)
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
In file included from trace/beauty/ioctl.c:106:
/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/perf_ioctl_array.c:1:20:
note: while referencing ‘perf_ioctl_cmds’
1 | static const char *perf_ioctl_cmds[] = {
| ^~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
> > about the -Wmissing-attributes I cleaned, they were these:
>
> > a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
> > init/cleanup_module")
> > c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >= 9)")
> > ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
> > aliases as __pure")
> >
> > Cheers,
> > Miguel
>
> --
>
> - Arnaldo
On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou <[email protected]> wrote:
>On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
><[email protected]> wrote:
>>
>> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
>> > On Fri, May 17, 2019 at 10:51 AM Greg KH
><[email protected]> wrote:
>> > >
>> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
>> > > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra
><[email protected]> wrote:
>> > > > >
>> > > > > Right; if there is anything you can reproduce on linus.git
>I'll happily
>> > > > > have a look. If it doesn't reproduce all you have to do is
>find the
>> > > > > patches that make it work and ask Greg.
>> > > >
>> > > > Just to clarify: Linus' master is clean of these issues with
>GCC 9.1.1.
>> > >
>> > > Great! Care to find the patches that did that work and send me
>the git
>> > > commit ids so that I can queue them up? I don't have gcc9 here
>yet on
>> > > my systems, so I can not test for this.
>> >
>> > I am unsure about the perf and the objtools parts (Peter/Josh?),
>but
>>
>> I'm not noticing these while building upstream perf with gcc 9.1.1 on
^^^^^^^^^^^^^^^
>at
>> least fedora:30.
>>
>> 33 fedora:30 : Ok gcc (GCC) 9.1.1 20190503
>(Red Hat 9.1.1-1)
>
>I've tried to replicate this in fedora:30 docker container and it's
>there:
>
>[root@linuxkit-025000000001 perf]# gcc --version
>gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
>
>[root@linuxkit-025000000001 perf]# pwd
>/tmp/linux-4.19.44/tools/perf
^^^^^^^^^^^^^^
That is not upstream perf, please look for patches from 4.19 to Linus' master Branch for fixes.
I'll triple check here in a f30 container just in case meanwhile.
Thanks,
- Arnaldo
>
>[root@linuxkit-025000000001 perf]# make -j1
>...
>trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_kvm_cmd’:
>trace/beauty/ioctl.c:85:82: error: array subscript [-2147483648, -1]
>is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> 85 | if (nr < strarray__kvm_ioctl_cmds.nr_entries &&
>strarray__kvm_ioctl_cmds.entries[nr] != NULL)
> |
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
>In file included from trace/beauty/ioctl.c:82:
>/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/kvm_ioctl_array.c:1:20:
>note: while referencing ‘kvm_ioctl_cmds’
> 1 | static const char *kvm_ioctl_cmds[] = {
> | ^~~~~~~~~~~~~~
>In file included from /usr/include/string.h:494,
> from util/debug.h:7,
> from builtin-help.c:15:
>In function ‘strncpy’,
> inlined from ‘add_man_viewer’ at builtin-help.c:192:2,
> inlined from ‘perf_help_config’ at builtin-help.c:284:3:
>/usr/include/bits/string_fortified.h:106:10: error:
>‘__builtin_strncpy’ output truncated before terminating nul copying as
>many bytes from a string as its length [-Werror=stringop-truncation]
>106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
>(__dest));
>|
>^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>builtin-help.c: In function ‘perf_help_config’:
>builtin-help.c:187:15: note: length computed here
> 187 | size_t len = strlen(name);
> | ^~~~~~~~~~~~
>trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_perf_cmd’:
>trace/beauty/ioctl.c:109:84: error: array subscript [-2147483648, -1]
>is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> 109 | if (nr < strarray__perf_ioctl_cmds.nr_entries &&
>strarray__perf_ioctl_cmds.entries[nr] != NULL)
> |
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
>In file included from trace/beauty/ioctl.c:106:
>/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/perf_ioctl_array.c:1:20:
>note: while referencing ‘perf_ioctl_cmds’
> 1 | static const char *perf_ioctl_cmds[] = {
> | ^~~~~~~~~~~~~~~
>cc1: all warnings being treated as errors
>
>> > about the -Wmissing-attributes I cleaned, they were these:
>>
>> > a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
>> > init/cleanup_module")
>> > c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >=
>9)")
>> > ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
>> > aliases as __pure")
>> >
>> > Cheers,
>> > Miguel
>>
>> --
>>
>> - Arnaldo
Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
perf still doesn't want to compile:
[07:15:32]In file included from /usr/include/string.h:635,
[07:15:32] from util/debug.h:7,
[07:15:32] from builtin-help.c:15:
[07:15:32]In function 'strncpy',
[07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
[07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
[07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
'__builtin_strncpy' output truncated before terminating nul copying as
many bytes from a string as its length [-Werror=stringop-truncation]
[07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
__bos (__dest));
[07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[07:15:32]builtin-help.c: In function 'perf_help_config':
[07:15:32]builtin-help.c:187:15: note: length computed here
[07:15:32] 187 | size_t len = strlen(name);
[07:15:32] | ^~~~~~~~~~~~
[07:15:32]cc1: all warnings being treated as errors
On Fri, May 17, 2019 at 11:27 AM Arnaldo Carvalho de Melo
<[email protected]> wrote:
>
> On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou <[email protected]> wrote:
> >On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
> ><[email protected]> wrote:
> >>
> >> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> >> > On Fri, May 17, 2019 at 10:51 AM Greg KH
> ><[email protected]> wrote:
> >> > >
> >> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> >> > > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra
> ><[email protected]> wrote:
> >> > > > >
> >> > > > > Right; if there is anything you can reproduce on linus.git
> >I'll happily
> >> > > > > have a look. If it doesn't reproduce all you have to do is
> >find the
> >> > > > > patches that make it work and ask Greg.
> >> > > >
> >> > > > Just to clarify: Linus' master is clean of these issues with
> >GCC 9.1.1.
> >> > >
> >> > > Great! Care to find the patches that did that work and send me
> >the git
> >> > > commit ids so that I can queue them up? I don't have gcc9 here
> >yet on
> >> > > my systems, so I can not test for this.
> >> >
> >> > I am unsure about the perf and the objtools parts (Peter/Josh?),
> >but
> >>
> >> I'm not noticing these while building upstream perf with gcc 9.1.1 on
> ^^^^^^^^^^^^^^^
>
> >at
> >> least fedora:30.
> >>
> >> 33 fedora:30 : Ok gcc (GCC) 9.1.1 20190503
> >(Red Hat 9.1.1-1)
> >
> >I've tried to replicate this in fedora:30 docker container and it's
> >there:
> >
> >[root@linuxkit-025000000001 perf]# gcc --version
> >gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
> >
> >[root@linuxkit-025000000001 perf]# pwd
> >/tmp/linux-4.19.44/tools/perf
> ^^^^^^^^^^^^^^
>
> That is not upstream perf, please look for patches from 4.19 to Linus' master Branch for fixes.
>
> I'll triple check here in a f30 container just in case meanwhile.
>
> Thanks,
>
> - Arnaldo
> >
> >[root@linuxkit-025000000001 perf]# make -j1
> >...
> >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_kvm_cmd’:
> >trace/beauty/ioctl.c:85:82: error: array subscript [-2147483648, -1]
> >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> > 85 | if (nr < strarray__kvm_ioctl_cmds.nr_entries &&
> >strarray__kvm_ioctl_cmds.entries[nr] != NULL)
> > |
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
> >In file included from trace/beauty/ioctl.c:82:
> >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/kvm_ioctl_array.c:1:20:
> >note: while referencing ‘kvm_ioctl_cmds’
> > 1 | static const char *kvm_ioctl_cmds[] = {
> > | ^~~~~~~~~~~~~~
> >In file included from /usr/include/string.h:494,
> > from util/debug.h:7,
> > from builtin-help.c:15:
> >In function ‘strncpy’,
> > inlined from ‘add_man_viewer’ at builtin-help.c:192:2,
> > inlined from ‘perf_help_config’ at builtin-help.c:284:3:
> >/usr/include/bits/string_fortified.h:106:10: error:
> >‘__builtin_strncpy’ output truncated before terminating nul copying as
> >many bytes from a string as its length [-Werror=stringop-truncation]
> >106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> >(__dest));
> >|
> >^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >builtin-help.c: In function ‘perf_help_config’:
> >builtin-help.c:187:15: note: length computed here
> > 187 | size_t len = strlen(name);
> > | ^~~~~~~~~~~~
> >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_perf_cmd’:
> >trace/beauty/ioctl.c:109:84: error: array subscript [-2147483648, -1]
> >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> > 109 | if (nr < strarray__perf_ioctl_cmds.nr_entries &&
> >strarray__perf_ioctl_cmds.entries[nr] != NULL)
> > |
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
> >In file included from trace/beauty/ioctl.c:106:
> >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/perf_ioctl_array.c:1:20:
> >note: while referencing ‘perf_ioctl_cmds’
> > 1 | static const char *perf_ioctl_cmds[] = {
> > | ^~~~~~~~~~~~~~~
> >cc1: all warnings being treated as errors
> >
> >> > about the -Wmissing-attributes I cleaned, they were these:
> >>
> >> > a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
> >> > init/cleanup_module")
> >> > c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >=
> >9)")
> >> > ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
> >> > aliases as __pure")
> >> >
> >> > Cheers,
> >> > Miguel
> >>
> >> --
> >>
> >> - Arnaldo
>
On Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou wrote:
> Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> perf still doesn't want to compile:
>
> [07:15:32]In file included from /usr/include/string.h:635,
> [07:15:32] from util/debug.h:7,
> [07:15:32] from builtin-help.c:15:
> [07:15:32]In function 'strncpy',
> [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> '__builtin_strncpy' output truncated before terminating nul copying as
> many bytes from a string as its length [-Werror=stringop-truncation]
> [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> __bos (__dest));
> [07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [07:15:32]builtin-help.c: In function 'perf_help_config':
> [07:15:32]builtin-help.c:187:15: note: length computed here
> [07:15:32] 187 | size_t len = strlen(name);
> [07:15:32] | ^~~~~~~~~~~~
> [07:15:32]cc1: all warnings being treated as errors
Any chance in finding a patch in Linus's tree that resolves this? I
don't have gcc9 on my systems here yet to test this.
thanks,
greg k-h
Hi Greg,
For us it seems applying the following 4 mainline patches makes 4.19.x
branch perf compile with GCC-9:
4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use
strlcpy() as a shorter form of strncpy() + explicit set nul
b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless
use of strncpy()
5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked
usage of strncpy()
97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may
truncate' build failure with recent gcc
I also checked that 4.19.49 compiles fine with GCC 9, although with a
lot of warnings, mostly from objtool, like "warning: objtool:
sock_register()+0xd: sibling call from callable instruction with
modified stack frame". But it's a start.
Can we apply the above-mentioned patches, please?
Regards,
Ignat
On Mon, Jun 10, 2019 at 8:45 AM Greg KH <[email protected]> wrote:
>
> On Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou wrote:
> > Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> > perf still doesn't want to compile:
> >
> > [07:15:32]In file included from /usr/include/string.h:635,
> > [07:15:32] from util/debug.h:7,
> > [07:15:32] from builtin-help.c:15:
> > [07:15:32]In function 'strncpy',
> > [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> > [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> > [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> > '__builtin_strncpy' output truncated before terminating nul copying as
> > many bytes from a string as its length [-Werror=stringop-truncation]
> > [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> > __bos (__dest));
> > [07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [07:15:32]builtin-help.c: In function 'perf_help_config':
> > [07:15:32]builtin-help.c:187:15: note: length computed here
> > [07:15:32] 187 | size_t len = strlen(name);
> > [07:15:32] | ^~~~~~~~~~~~
> > [07:15:32]cc1: all warnings being treated as errors
>
>
> Any chance in finding a patch in Linus's tree that resolves this? I
> don't have gcc9 on my systems here yet to test this.
>
> thanks,
>
> greg k-h
>
> --
> You received this message because you are subscribed to the Google Groups "kernel-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
> To view this discussion on the web visit https://groups.google.com/a/cloudflare.com/d/msgid/kernel-team/20190610074510.GA24746%40kroah.com.
On Mon, Jun 10, 2019 at 10:32:25AM +0100, Ignat Korchagin wrote:
> Hi Greg,
>
> For us it seems applying the following 4 mainline patches makes 4.19.x
> branch perf compile with GCC-9:
>
> 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use
> strlcpy() as a shorter form of strncpy() + explicit set nul
> b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless
> use of strncpy()
> 5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked
> usage of strncpy()
> 97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may
> truncate' build failure with recent gcc
>
> I also checked that 4.19.49 compiles fine with GCC 9, although with a
> lot of warnings, mostly from objtool, like "warning: objtool:
> sock_register()+0xd: sibling call from callable instruction with
> modified stack frame". But it's a start.
>
> Can we apply the above-mentioned patches, please?
I'll look into these after the next round of kernels are released. I
guess I'll go find a distro that has gcc9 on it to actually test
things...
thanks,
greg k-h
On Mon, Jun 10, 2019 at 4:21 PM Greg KH <[email protected]> wrote:
>
> > I also checked that 4.19.49 compiles fine with GCC 9, although with a
> > lot of warnings, mostly from objtool, like "warning: objtool:
> > sock_register()+0xd: sibling call from callable instruction with
> > modified stack frame". But it's a start.
I think Josh Poimboeuf added support for a few related things in GCC 8
(e.g. 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")).
> I'll look into these after the next round of kernels are released. I
> guess I'll go find a distro that has gcc9 on it to actually test
> things...
I typically compile a bare-bones GCC for those things, it is quite quick.
Cheers,
Miguel
On Mon, Jun 10, 2019 at 04:42:27PM +0200, Miguel Ojeda wrote:
> On Mon, Jun 10, 2019 at 4:21 PM Greg KH <[email protected]> wrote:
> >
> > > I also checked that 4.19.49 compiles fine with GCC 9, although with a
> > > lot of warnings, mostly from objtool, like "warning: objtool:
> > > sock_register()+0xd: sibling call from callable instruction with
> > > modified stack frame". But it's a start.
>
> I think Josh Poimboeuf added support for a few related things in GCC 8
> (e.g. 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")).
That commit is already in all stable releases, so does there need to be
a gcc 9 specific one?
> > I'll look into these after the next round of kernels are released. I
> > guess I'll go find a distro that has gcc9 on it to actually test
> > things...
>
> I typically compile a bare-bones GCC for those things, it is quite quick.
Pointers to how to do that is appreciated. It's been years since I had
to build gcc "from scratch".
thanks,
greg k-h
On Mon, Jun 10, 2019 at 3:49 PM Greg KH <[email protected]> wrote:
>
> >
> > I typically compile a bare-bones GCC for those things, it is quite quick.
>
> Pointers to how to do that is appreciated. It's been years since I had
> to build gcc "from scratch".
This is how we do it, but we use it for some other projects as well,
so need ligcc and c++ support. I suspect for kernel-only there may be
a more lightweight approach (for example, by dropping c++):
Env: Debian Stretch (we run in a simple official docker container with
build-essential and make installed) - but probably should work on any
distro
Assuming the sources are extracted into $(BUILDDIR)/gcc-$(VERSION)
cd $(BUILDDIR)/gcc-$(VERSION)
./contrib/download_prerequisites
cd ..
mkdir gcc-build
cd gcc-build
../gcc-$(VERSION)/configure --enable-languages=c,c++
--build=x86_64-linux-gnu --disable-multilib
make -j<something>
sudo make install (or install into alternative dir and point Linux
build system there)
Regards,
Ignat
On Mon, Jun 10, 2019 at 4:49 PM Greg KH <[email protected]> wrote:
>
> On Mon, Jun 10, 2019 at 04:42:27PM +0200, Miguel Ojeda wrote:
> > I think Josh Poimboeuf added support for a few related things in GCC 8
> > (e.g. 13810435b9a7 ("objtool: Support GCC 8's cold subfunctions")).
>
> That commit is already in all stable releases, so does there need to be
> a gcc 9 specific one?
Ah, you are right. Hm... I recall discussing this at some point when
cleaning up for GCC 9, let me take a look...
> > I typically compile a bare-bones GCC for those things, it is quite quick.
>
> Pointers to how to do that is appreciated. It's been years since I had
> to build gcc "from scratch".
We crossed emails -- I copy it here on-list in case someone else wants it :-)
mkdir ${BUILD_PATH} \
&& cd ${BUILD_PATH} \
&& ${REPO_PATH}/configure \
--enable-languages=c,c++ \
--disable-multilib \
--disable-bootstrap \
--disable-nls \
--prefix=${INSTALL_PATH} \
&& time make \
&& time make install
The key thing is disabling bootstrap to have a single-pass compilation
-- that speeds up things a lot (although, of course, you get less
testing). I would guess you can also disable c++ for the kernel for
even a faster build. You can also use -j, but even without it it does
not really take long (1 hour? -- way less than LLVM anyway). The
installed size nowadays is about 1 GiB.
To get the actual code, I use the git mirror in github for speed
(although it is not that big anyway):
git clone https://github.com/gcc-mirror/gcc
The tags you want to use look like:
gcc-9_1_0-release
Also, the first time you run this, you may need some extra dependencies:
libgmp-dev (maybe named gmp-devel)
libmpfr-dev (mpfr-devel)
libmpc-dev (libmpc-devel)
Unless your distro is quite old, I think they should simply work (a
few years ago I had to compile those manually, but nowadays I don't
seem to need them anymore).
Cheers,
Miguel
Em Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou escreveu:
> Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> perf still doesn't want to compile:
>
> [07:15:32]In file included from /usr/include/string.h:635,
> [07:15:32] from util/debug.h:7,
> [07:15:32] from builtin-help.c:15:
> [07:15:32]In function 'strncpy',
> [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> '__builtin_strncpy' output truncated before terminating nul copying as
> many bytes from a string as its length [-Werror=stringop-truncation]
> [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> __bos (__dest));
> [07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> [07:15:32]builtin-help.c: In function 'perf_help_config':
> [07:15:32]builtin-help.c:187:15: note: length computed here
> [07:15:32] 187 | size_t len = strlen(name);
> [07:15:32] | ^~~~~~~~~~~~
> [07:15:32]cc1: all warnings being treated as errors
The patch below should've taken care of that, and it has a Fixes: tag,
i.e. the stable scripts should've noticed that, and it was noticed with
gcc 8.2.
- Arnaldo
commit b6313899f4ed2e76b8375cf8069556f5b94fbff0
Author: Arnaldo Carvalho de Melo <[email protected]>
Date: Thu Dec 6 11:20:21 2018 -0300
perf help: Remove needless use of strncpy()
Since we make sure the destination buffer has at least strlen(orig) + 1,
no need to do a strncpy(dest, orig, strlen(orig)), just use strcpy(dest,
orig).
This silences this gcc 8.2 warning on Alpine Linux:
In function 'add_man_viewer',
inlined from 'perf_help_config' at builtin-help.c:284:3:
builtin-help.c:192:2: error: 'strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
strncpy((*p)->name, name, len);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
builtin-help.c: In function 'perf_help_config':
builtin-help.c:187:15: note: length computed here
size_t len = strlen(name);
^~~~~~~~~~~~
Cc: Adrian Hunter <[email protected]>
Cc: Jiri Olsa <[email protected]>
Cc: Namhyung Kim <[email protected]>
Fixes: 078006012401 ("perf_counter tools: add in basic glue from Git")
Link: https://lkml.kernel.org/n/[email protected]
Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
> On Fri, May 17, 2019 at 11:27 AM Arnaldo Carvalho de Melo
> <[email protected]> wrote:
> >
> > On May 17, 2019 2:23:10 PM GMT-03:00, Ivan Babrou <[email protected]> wrote:
> > >On Fri, May 17, 2019 at 8:22 AM Arnaldo Carvalho de Melo
> > ><[email protected]> wrote:
> > >>
> > >> Em Fri, May 17, 2019 at 11:01:45AM +0200, Miguel Ojeda escreveu:
> > >> > On Fri, May 17, 2019 at 10:51 AM Greg KH
> > ><[email protected]> wrote:
> > >> > >
> > >> > > On Fri, May 17, 2019 at 10:35:29AM +0200, Miguel Ojeda wrote:
> > >> > > > On Fri, May 17, 2019 at 9:38 AM Peter Zijlstra
> > ><[email protected]> wrote:
> > >> > > > >
> > >> > > > > Right; if there is anything you can reproduce on linus.git
> > >I'll happily
> > >> > > > > have a look. If it doesn't reproduce all you have to do is
> > >find the
> > >> > > > > patches that make it work and ask Greg.
> > >> > > >
> > >> > > > Just to clarify: Linus' master is clean of these issues with
> > >GCC 9.1.1.
> > >> > >
> > >> > > Great! Care to find the patches that did that work and send me
> > >the git
> > >> > > commit ids so that I can queue them up? I don't have gcc9 here
> > >yet on
> > >> > > my systems, so I can not test for this.
> > >> >
> > >> > I am unsure about the perf and the objtools parts (Peter/Josh?),
> > >but
> > >>
> > >> I'm not noticing these while building upstream perf with gcc 9.1.1 on
> > ^^^^^^^^^^^^^^^
> >
> > >at
> > >> least fedora:30.
> > >>
> > >> 33 fedora:30 : Ok gcc (GCC) 9.1.1 20190503
> > >(Red Hat 9.1.1-1)
> > >
> > >I've tried to replicate this in fedora:30 docker container and it's
> > >there:
> > >
> > >[root@linuxkit-025000000001 perf]# gcc --version
> > >gcc (GCC) 9.1.1 20190503 (Red Hat 9.1.1-1)
> > >
> > >[root@linuxkit-025000000001 perf]# pwd
> > >/tmp/linux-4.19.44/tools/perf
> > ^^^^^^^^^^^^^^
> >
> > That is not upstream perf, please look for patches from 4.19 to Linus' master Branch for fixes.
> >
> > I'll triple check here in a f30 container just in case meanwhile.
> >
> > Thanks,
> >
> > - Arnaldo
> > >
> > >[root@linuxkit-025000000001 perf]# make -j1
> > >...
> > >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_kvm_cmd’:
> > >trace/beauty/ioctl.c:85:82: error: array subscript [-2147483648, -1]
> > >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> > > 85 | if (nr < strarray__kvm_ioctl_cmds.nr_entries &&
> > >strarray__kvm_ioctl_cmds.entries[nr] != NULL)
> > > |
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
> > >In file included from trace/beauty/ioctl.c:82:
> > >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/kvm_ioctl_array.c:1:20:
> > >note: while referencing ‘kvm_ioctl_cmds’
> > > 1 | static const char *kvm_ioctl_cmds[] = {
> > > | ^~~~~~~~~~~~~~
> > >In file included from /usr/include/string.h:494,
> > > from util/debug.h:7,
> > > from builtin-help.c:15:
> > >In function ‘strncpy’,
> > > inlined from ‘add_man_viewer’ at builtin-help.c:192:2,
> > > inlined from ‘perf_help_config’ at builtin-help.c:284:3:
> > >/usr/include/bits/string_fortified.h:106:10: error:
> > >‘__builtin_strncpy’ output truncated before terminating nul copying as
> > >many bytes from a string as its length [-Werror=stringop-truncation]
> > >106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> > >(__dest));
> > >|
> > >^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > >builtin-help.c: In function ‘perf_help_config’:
> > >builtin-help.c:187:15: note: length computed here
> > > 187 | size_t len = strlen(name);
> > > | ^~~~~~~~~~~~
> > >trace/beauty/ioctl.c: In function ‘ioctl__scnprintf_perf_cmd’:
> > >trace/beauty/ioctl.c:109:84: error: array subscript [-2147483648, -1]
> > >is outside array bounds of ‘const char *[0]’ [-Werror=array-bounds]
> > > 109 | if (nr < strarray__perf_ioctl_cmds.nr_entries &&
> > >strarray__perf_ioctl_cmds.entries[nr] != NULL)
> > > |
> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
> > >In file included from trace/beauty/ioctl.c:106:
> > >/tmp/linux-4.19.44/tools/perf/trace/beauty/generated/ioctl/perf_ioctl_array.c:1:20:
> > >note: while referencing ‘perf_ioctl_cmds’
> > > 1 | static const char *perf_ioctl_cmds[] = {
> > > | ^~~~~~~~~~~~~~~
> > >cc1: all warnings being treated as errors
> > >
> > >> > about the -Wmissing-attributes I cleaned, they were these:
> > >>
> > >> > a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to
> > >> > init/cleanup_module")
> > >> > c0d9782f5b6d ("Compiler Attributes: add support for __copy (gcc >=
> > >9)")
> > >> > ff98e20ef208 ("lib/crc32.c: mark crc32_le_base/__crc32c_le_base
> > >> > aliases as __pure")
> > >> >
> > >> > Cheers,
> > >> > Miguel
> > >>
> > >> --
> > >>
> > >> - Arnaldo
> >
--
- Arnaldo
On Mon, Jun 10, 2019 at 12:14:07PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou escreveu:
> > Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> > perf still doesn't want to compile:
> >
> > [07:15:32]In file included from /usr/include/string.h:635,
> > [07:15:32] from util/debug.h:7,
> > [07:15:32] from builtin-help.c:15:
> > [07:15:32]In function 'strncpy',
> > [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> > [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> > [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> > '__builtin_strncpy' output truncated before terminating nul copying as
> > many bytes from a string as its length [-Werror=stringop-truncation]
> > [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> > __bos (__dest));
> > [07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > [07:15:32]builtin-help.c: In function 'perf_help_config':
> > [07:15:32]builtin-help.c:187:15: note: length computed here
> > [07:15:32] 187 | size_t len = strlen(name);
> > [07:15:32] | ^~~~~~~~~~~~
> > [07:15:32]cc1: all warnings being treated as errors
>
> The patch below should've taken care of that, and it has a Fixes: tag,
> i.e. the stable scripts should've noticed that, and it was noticed with
> gcc 8.2.
No, stable scripts do not always pick up the "Fixes:" tag, they are only
guaranteed to pick up the "cc: stable@" tag. Sometimes we catch the
fixes ones too, but not always by far.
Anyway, I'll queue this patch up after this next round of kernels are
released, thanks!
greg k-h
Em Mon, Jun 10, 2019 at 05:25:42PM +0200, Greg KH escreveu:
> On Mon, Jun 10, 2019 at 12:14:07PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Jun 10, 2019 at 12:21:51AM -0700, Ivan Babrou escreveu:
> > > Looks like 4.19.49 received some patches for GCC 9+, but unfortunately
> > > perf still doesn't want to compile:
> > >
> > > [07:15:32]In file included from /usr/include/string.h:635,
> > > [07:15:32] from util/debug.h:7,
> > > [07:15:32] from builtin-help.c:15:
> > > [07:15:32]In function 'strncpy',
> > > [07:15:32] inlined from 'add_man_viewer' at builtin-help.c:192:2,
> > > [07:15:32] inlined from 'perf_help_config' at builtin-help.c:284:3:
> > > [07:15:32]/usr/include/x86_64-linux-gnu/bits/string3.h:126:10: error:
> > > '__builtin_strncpy' output truncated before terminating nul copying as
> > > many bytes from a string as its length [-Werror=stringop-truncation]
> > > [07:15:32] 126 | return __builtin___strncpy_chk (__dest, __src, __len,
> > > __bos (__dest));
> > > [07:15:32] | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > [07:15:32]builtin-help.c: In function 'perf_help_config':
> > > [07:15:32]builtin-help.c:187:15: note: length computed here
> > > [07:15:32] 187 | size_t len = strlen(name);
> > > [07:15:32] | ^~~~~~~~~~~~
> > > [07:15:32]cc1: all warnings being treated as errors
> >
> > The patch below should've taken care of that, and it has a Fixes: tag,
> > i.e. the stable scripts should've noticed that, and it was noticed with
> > gcc 8.2.
>
> No, stable scripts do not always pick up the "Fixes:" tag, they are only
Humm, I thought it picked those, or is it that AUTOSEL thing? Ok, I'll
add stable@ when I add Fixes: then.
> guaranteed to pick up the "cc: stable@" tag. Sometimes we catch the
> fixes ones too, but not always by far.
>
> Anyway, I'll queue this patch up after this next round of kernels are
> released, thanks!
>
> greg k-h
--
- Arnaldo
Hi Greg,
> > For us it seems applying the following 4 mainline patches makes 4.19.x
> > branch perf compile with GCC-9:
> >
> > 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use
> > strlcpy() as a shorter form of strncpy() + explicit set nul
> > b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless
> > use of strncpy()
> > 5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked
> > usage of strncpy()
> > 97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may
> > truncate' build failure with recent gcc
> >
> > I also checked that 4.19.49 compiles fine with GCC 9, although with a
> > lot of warnings, mostly from objtool, like "warning: objtool:
> > sock_register()+0xd: sibling call from callable instruction with
> > modified stack frame". But it's a start.
> >
> > Can we apply the above-mentioned patches, please?
> I'll look into these after the next round of kernels are released. I
Did you by any chance forget to queue these patches? :) (the build is
still broken for GCC 9.1)
> guess I'll go find a distro that has gcc9 on it to actually test
> things...
BTW, Arch already has GCC 9.1 package, so no need to compile your own
anymore for testing:
https://www.archlinux.org/packages/core/x86_64/gcc/
Regards,
Ignat
On Mon, Jun 24, 2019 at 11:42:34AM +0100, Ignat Korchagin wrote:
> Hi Greg,
>
> > > For us it seems applying the following 4 mainline patches makes 4.19.x
> > > branch perf compile with GCC-9:
> > >
> > > 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use
> > > strlcpy() as a shorter form of strncpy() + explicit set nul
> > > b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless
> > > use of strncpy()
> > > 5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked
> > > usage of strncpy()
> > > 97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may
> > > truncate' build failure with recent gcc
> > >
> > > I also checked that 4.19.49 compiles fine with GCC 9, although with a
> > > lot of warnings, mostly from objtool, like "warning: objtool:
> > > sock_register()+0xd: sibling call from callable instruction with
> > > modified stack frame". But it's a start.
> > >
> > > Can we apply the above-mentioned patches, please?
>
> > I'll look into these after the next round of kernels are released. I
>
> Did you by any chance forget to queue these patches? :) (the build is
> still broken for GCC 9.1)
I am on the road and getting to backports for this stuff is on the
bottom of my list until next week at the earliest, sorry.
> > guess I'll go find a distro that has gcc9 on it to actually test
> > things...
>
> BTW, Arch already has GCC 9.1 package, so no need to compile your own
> anymore for testing:
> https://www.archlinux.org/packages/core/x86_64/gcc/
Yes, my laptop just updated, so I'm building here. Some gcc9 patches
did just get backported, but not for perf.
thanks,
greg k-h
On Tue, Jun 25, 2019 at 03:50:29PM +0800, Greg KH wrote:
> On Mon, Jun 24, 2019 at 11:42:34AM +0100, Ignat Korchagin wrote:
> > Hi Greg,
> >
> > > > For us it seems applying the following 4 mainline patches makes 4.19.x
> > > > branch perf compile with GCC-9:
> > > >
> > > > 4d0f16d059ddb91424480d88473f7392f24aebdc: perf ui helpline: Use
> > > > strlcpy() as a shorter form of strncpy() + explicit set nul
> > > > b6313899f4ed2e76b8375cf8069556f5b94fbff0: perf help: Remove needless
> > > > use of strncpy()
> > > > 5192bde7d98c99f2cd80225649e3c2e7493722f7: perf header: Fix unchecked
> > > > usage of strncpy()
> > > > 97acec7df172cd1e450f81f5e293c0aa145a2797: perf data: Fix 'strncat may
> > > > truncate' build failure with recent gcc
> > > >
> > > > I also checked that 4.19.49 compiles fine with GCC 9, although with a
> > > > lot of warnings, mostly from objtool, like "warning: objtool:
> > > > sock_register()+0xd: sibling call from callable instruction with
> > > > modified stack frame". But it's a start.
> > > >
> > > > Can we apply the above-mentioned patches, please?
> >
> > > I'll look into these after the next round of kernels are released. I
> >
> > Did you by any chance forget to queue these patches? :) (the build is
> > still broken for GCC 9.1)
>
> I am on the road and getting to backports for this stuff is on the
> bottom of my list until next week at the earliest, sorry.
Oh nevermind, I just queued them up now.
If there are any other gcc9 patches that you see that I've missed,
please let me know.
Now, to try to track down the fix for all of those build warnings, those
need to get fixed up...
thanks,
greg k-h