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@arm.com>
---
tools/perf/arch/arm64/util/pmu.c | 6 +++---
tools/perf/tests/expr.c | 2 +-
tools/perf/util/expr.c | 2 +-
tools/perf/util/pmu.c | 17 -----------------
tools/perf/util/pmu.h | 2 +-
tools/perf/util/pmus.c | 18 ++++++++++++++++++
6 files changed, 24 insertions(+), 23 deletions(-)
diff --git a/tools/perf/arch/arm64/util/pmu.c b/tools/perf/arch/arm64/util/pmu.c
index 615084eb88d8..3d9330feebd2 100644
--- a/tools/perf/arch/arm64/util/pmu.c
+++ b/tools/perf/arch/arm64/util/pmu.c
@@ -10,7 +10,7 @@
const struct pmu_metrics_table *pmu_metrics_table__find(void)
{
- struct perf_pmu *pmu = pmu__find_core_pmu();
+ struct perf_pmu *pmu = perf_pmus__find_core_pmu();
if (pmu)
return perf_pmu__find_metrics_table(pmu);
@@ -20,7 +20,7 @@ const struct pmu_metrics_table *pmu_metrics_table__find(void)
const struct pmu_events_table *pmu_events_table__find(void)
{
- struct perf_pmu *pmu = pmu__find_core_pmu();
+ struct perf_pmu *pmu = perf_pmus__find_core_pmu();
if (pmu)
return perf_pmu__find_events_table(pmu);
@@ -32,7 +32,7 @@ double perf_pmu__cpu_slots_per_cycle(void)
{
char path[PATH_MAX];
unsigned long long slots = 0;
- struct perf_pmu *pmu = pmu__find_core_pmu();
+ struct perf_pmu *pmu = perf_pmus__find_core_pmu();
if (pmu) {
perf_pmu__pathname_scnprintf(path, sizeof(path),
diff --git a/tools/perf/tests/expr.c b/tools/perf/tests/expr.c
index 78544092ef0c..e3aa9d4fcf3a 100644
--- a/tools/perf/tests/expr.c
+++ b/tools/perf/tests/expr.c
@@ -76,7 +76,7 @@ static int test__expr(struct test_suite *t __maybe_unused, int subtest __maybe_u
struct expr_parse_ctx *ctx;
bool is_intel = false;
char strcmp_cpuid_buf[256];
- struct perf_pmu *pmu = pmu__find_core_pmu();
+ struct perf_pmu *pmu = perf_pmus__find_core_pmu();
char *cpuid = perf_pmu__getcpuid(pmu);
char *escaped_cpuid1, *escaped_cpuid2;
diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
index 4488f306de78..7be23b3ac082 100644
--- a/tools/perf/util/expr.c
+++ b/tools/perf/util/expr.c
@@ -509,7 +509,7 @@ double expr__strcmp_cpuid_str(const struct expr_parse_ctx *ctx __maybe_unused,
bool compute_ids __maybe_unused, const char *test_id)
{
double ret;
- struct perf_pmu *pmu = pmu__find_core_pmu();
+ struct perf_pmu *pmu = perf_pmus__find_core_pmu();
char *cpuid = perf_pmu__getcpuid(pmu);
if (!cpuid)
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 152cda84f273..8213e26783a1 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -2049,20 +2049,3 @@ void perf_pmu__delete(struct perf_pmu *pmu)
zfree(&pmu->id);
free(pmu);
}
-
-struct perf_pmu *pmu__find_core_pmu(void)
-{
- struct perf_pmu *pmu = NULL;
-
- while ((pmu = perf_pmus__scan_core(pmu))) {
- /*
- * The cpumap should cover all CPUs. Otherwise, some CPUs may
- * not support some events or have different event IDs.
- */
- if (RC_CHK_ACCESS(pmu->cpus)->nr != cpu__max_cpu().cpu)
- return NULL;
-
- return pmu;
- }
- return NULL;
-}
diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
index 6a4e170c61d6..45079f26abf6 100644
--- a/tools/perf/util/pmu.h
+++ b/tools/perf/util/pmu.h
@@ -264,6 +264,6 @@ int perf_pmu__pathname_fd(int dirfd, const char *pmu_name, const char *filename,
struct perf_pmu *perf_pmu__lookup(struct list_head *pmus, int dirfd, const char *lookup_name);
struct perf_pmu *perf_pmu__create_placeholder_core_pmu(struct list_head *core_pmus);
void perf_pmu__delete(struct perf_pmu *pmu);
-struct perf_pmu *pmu__find_core_pmu(void);
+struct perf_pmu *perf_pmus__find_core_pmu(void);
#endif /* __PMU_H */
diff --git a/tools/perf/util/pmus.c b/tools/perf/util/pmus.c
index 6631367c756f..032ce57d2b8e 100644
--- a/tools/perf/util/pmus.c
+++ b/tools/perf/util/pmus.c
@@ -10,6 +10,7 @@
#include <pthread.h>
#include <string.h>
#include <unistd.h>
+#include "cpumap.h"
#include "debug.h"
#include "evsel.h"
#include "pmus.h"
@@ -592,3 +593,20 @@ struct perf_pmu *evsel__find_pmu(const struct evsel *evsel)
}
return pmu;
}
+
+struct perf_pmu *perf_pmus__find_core_pmu(void)
+{
+ struct perf_pmu *pmu = NULL;
+
+ while ((pmu = perf_pmus__scan_core(pmu))) {
+ /*
+ * The cpumap should cover all CPUs. Otherwise, some CPUs may
+ * not support some events or have different event IDs.
+ */
+ if (RC_CHK_ACCESS(pmu->cpus)->nr != cpu__max_cpu().cpu)
+ return NULL;
+
+ return pmu;
+ }
+ return NULL;
+}
--
2.34.1Em 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@arm.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
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@arm.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); \
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@arm.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.
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@arm.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.
© 2016 - 2025 Red Hat, Inc.