[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <36a4405d-0133-5ee7-4bdf-b85a26defb4f@arm.com>
Date: Wed, 13 Sep 2023 16:37:27 +0100
From: James Clark <james.clark@....com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: linux-perf-users@...r.kernel.org, irogers@...gle.com,
John Garry <john.g.garry@...cle.com>,
Will Deacon <will@...nel.org>,
Mike Leach <mike.leach@...aro.org>,
Leo Yan <leo.yan@...aro.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Jing Zhang <renyu.zj@...ux.alibaba.com>,
Haixin Yu <yuhaixin.yhx@...ux.alibaba.com>,
Kajol Jain <kjain@...ux.ibm.com>,
Ravi Bangoria <ravi.bangoria@....com>,
Yang Jihong <yangjihong1@...wei.com>,
Eduard Zingerman <eddyz87@...il.com>,
Chen Zhongjin <chenzhongjin@...wei.com>,
Miguel Ojeda <ojeda@...nel.org>,
Liam Howlett <liam.howlett@...cle.com>,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 5/7] perf pmu: Move pmu__find_core_pmu() to pmus.c
On 13/09/2023 11:32, James Clark wrote:
>
>
> On 13/09/2023 11:20, James Clark wrote:
>>
>>
>> On 12/09/2023 20:26, Arnaldo Carvalho de Melo wrote:
>>> Em Thu, Aug 31, 2023 at 04:16:16PM +0100, James Clark escreveu:
>>>> pmu__find_core_pmu() more logically belongs in pmus.c because it
>>>> iterates over all PMUs, so move it to pmus.c
>>>>
>>>> At the same time rename it to perf_pmus__find_core_pmu() to match the
>>>> naming convention in this file.
>>>>
>>>> Signed-off-by: James Clark <james.clark@....com>
>>>
>>> So, this one is hitting this:
>>>
>>> CC /tmp/build/perf-tools-next/util/expr.o
>>> In file included from /var/home/acme/git/perf-tools-next/tools/include/linux/list.h:7,
>>> from util/pmus.c:2:
>>> In function ‘perf_pmus__scan_core’,
>>> inlined from ‘perf_pmus__find_core_pmu’ at util/pmus.c:601:16:
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/kernel.h:36:45: error: array subscript 0 is outside array bounds of ‘struct list_head[1]’ [-Werror=array-bounds]
>>> 36 | const typeof(((type *)0)->member) * __mptr = (ptr); \
>>> | ^~~~~~
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/list.h:352:9: note: in expansion of macro ‘container_of’
>>> 352 | container_of(ptr, type, member)
>>> | ^~~~~~~~~~~~
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/list.h:404:9: note: in expansion of macro ‘list_entry’
>>> 404 | list_entry((pos)->member.next, typeof(*(pos)), member)
>>> | ^~~~~~~~~~
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/list.h:494:20: note: in expansion of macro ‘list_next_entry’
>>> 494 | for (pos = list_next_entry(pos, member); \
>>> | ^~~~~~~~~~~~~~~
>>> util/pmus.c:274:9: note: in expansion of macro ‘list_for_each_entry_continue’
>>> 274 | list_for_each_entry_continue(pmu, &core_pmus, list)
>>> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> util/pmus.c: In function ‘perf_pmus__find_core_pmu’:
>>> util/pmus.c:35:18: note: at offset -128 into object ‘core_pmus’ of size 16
>>> 35 | static LIST_HEAD(core_pmus);
>>> | ^~~~~~~~~
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/list.h:23:26: note: in definition of macro ‘LIST_HEAD’
>>> 23 | struct list_head name = LIST_HEAD_INIT(name)
>>> | ^~~~
>>> cc1: all warnings being treated as errors
>>> make[4]: *** [/var/home/acme/git/perf-tools-next/tools/build/Makefile.build:97: /tmp/build/perf-tools-next/util/pmus.o] Error 1
>>> make[4]: *** Waiting for unfinished jobs....
>>> LD /tmp/build/perf-tools-next/ui/browsers/perf-in.o
>>>
>>>
>>> So I applied up to 4/7
>>>
>>> Please continue from what will be in tmp.perf-tools-next in some
>>> jiffies.
>>>
>>> - Arnaldo
>>
>> I wasn't able to reproduce this on x86 or Arm, with either Clang or GCC.
>>
>> That was with this patch applied onto 999b81b907e on tmp.perf-tools-next
>> and a pretty normal "make WERROR=1" command.
>>
>> It seems like the 0 here is just to get the type rather than access
>> anything, if that's the 0 that the "array subscript 0" error is about,
>> so something seems a bit strange:
>>
>>> /var/home/acme/git/perf-tools-next/tools/include/linux/kernel.h:36:45:
>> error: array subscript 0 is outside array bounds of ‘struct
>> list_head[1]’ [-Werror=array-bounds]
>>> 36 | const typeof(((type *)0)->member) * __mptr = (ptr); \
>
> Nevermind, I managed to reproduce it. With a DEBUG=1 build on x86 there
> is no error, it only happens with a non debug one.
>
> I will look into it.
Sent a v3 with the fix. It's some kind of awkward semi-undefined
behavior in the linked list implementation that was always there but the
compiler could only see when I moved that function so it was all in one
compilation unit. It also required -O2 and I always build with DEBUG=1
so I missed it.
Powered by blists - more mailing lists