| Message ID | 20210806134109.1182235-10-james.clark@arm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Support ETE decoding | expand |
On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > Currently perf reports "Cannot allocate memory" which isn't very helpful > for a potentially user facing issue. If we add a new magic number in > the future, perf will be able to report unrecognised magic numbers. > > Signed-off-by: James Clark <james.clark@arm.com> Reviewed-by: Leo Yan <leo.yan@linaro.org> > --- > tools/perf/util/cs-etm.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c > index 788ad5a099f6..5b276bdb96a6 100644 > --- a/tools/perf/util/cs-etm.c > +++ b/tools/perf/util/cs-etm.c > @@ -2973,6 +2973,11 @@ int cs_etm__process_auxtrace_info(union perf_event *event, > > /* ETE shares first part of metadata with ETMv4 */ > trcidr_idx = CS_ETMV4_TRCTRACEIDR; > + } else { > + ui__error("CS ETM Trace: Unrecognised magic number %#"PRIx64". File could be from a newer version of perf.\n", > + ptr[i]); > + err = -EINVAL; > + goto err_free_metadata; > } > > if (!metadata[j]) { > -- > 2.28.0 >
Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > for a potentially user facing issue. If we add a new magic number in > > the future, perf will be able to report unrecognised magic numbers. > > > > Signed-off-by: James Clark <james.clark@arm.com> > > Reviewed-by: Leo Yan <leo.yan@linaro.org> Applies cleanly to my tree, test building it now, holler if there is something that prevents it from being merged. - Arnaldo > > --- > > tools/perf/util/cs-etm.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c > > index 788ad5a099f6..5b276bdb96a6 100644 > > --- a/tools/perf/util/cs-etm.c > > +++ b/tools/perf/util/cs-etm.c > > @@ -2973,6 +2973,11 @@ int cs_etm__process_auxtrace_info(union perf_event *event, > > > > /* ETE shares first part of metadata with ETMv4 */ > > trcidr_idx = CS_ETMV4_TRCTRACEIDR; > > + } else { > > + ui__error("CS ETM Trace: Unrecognised magic number %#"PRIx64". File could be from a newer version of perf.\n", > > + ptr[i]); > > + err = -EINVAL; > > + goto err_free_metadata; > > } > > > > if (!metadata[j]) { > > -- > > 2.28.0 > >
Em Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > for a potentially user facing issue. If we add a new magic number in > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > Applies cleanly to my tree, test building it now, holler if there is > something that prevents it from being merged. I´m now trying to fix this up, I applied it using 'b4', so no patch should have gone missing... ⬢[acme@toolbox perf]$ time make -C tools/perf build-test make: Entering directory '/var/home/acme/git/perf/tools/perf' - tarpkg: ./tests/perf-targz-src-pkg . make_static: cd . && make LDFLAGS=-static NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 NO_JVMTI=1 -j24 DESTDIR=/tmp/tmp.tw23W3JC1W make_with_gtk2: cd . && make GTK2=1 -j24 DESTDIR=/tmp/tmp.F7gN4e98pK make_tags_O: cd . && make tags FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.tQVbhFdXKU DESTDIR=/tmp/tmp.1vbvWgUYUv make_no_slang_O: cd . && make NO_SLANG=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.2L0POmKIip DESTDIR=/tmp/tmp.0qTYEQTY8e make_no_demangle_O: cd . && make NO_DEMANGLE=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.Wh3kRYOFJo DESTDIR=/tmp/tmp.ih1nESGU6N make_no_sdt_O: cd . && make NO_SDT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.zw3NugHqvZ DESTDIR=/tmp/tmp.li1bxbfYOZ make_no_backtrace_O: cd . && make NO_BACKTRACE=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.66VxfiD04f DESTDIR=/tmp/tmp.PIgwBwGEZz make_install_prefix_O: cd . && make install prefix=/tmp/krava FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.s6u85zKKjU DESTDIR=/tmp/tmp.2FJoF1mCRB make_with_coresight_O: cd . && make CORESIGHT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.kQs4YxWFpL DESTDIR=/tmp/tmp.z93leAThcc cd . && make CORESIGHT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.kQs4YxWFpL DESTDIR=/tmp/tmp.z93leAThcc BUILD: Doing 'make -j24' parallel build HOSTCC /tmp/tmp.kQs4YxWFpL/fixdep.o HOSTLD /tmp/tmp.kQs4YxWFpL/fixdep-in.o LINK /tmp/tmp.kQs4YxWFpL/fixdep Makefile.config:1038: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel GEN /tmp/tmp.kQs4YxWFpL/common-cmds.h CC /tmp/tmp.kQs4YxWFpL/exec-cmd.o CC /tmp/tmp.kQs4YxWFpL/help.o <SNIP> CC /tmp/tmp.kQs4YxWFpL/util/auxtrace.o MKDIR /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/ CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-pkt-decoder.o MKDIR /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/ MKDIR /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/ CC /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/arm-spe-pkt-decoder.o CC /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/arm-spe-decoder.o MKDIR /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/ GEN /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/inat-tables.c MKDIR /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/ CC /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/cs-etm-decoder.o CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-log.o MKDIR /tmp/tmp.kQs4YxWFpL/util/scripting-engines/ CC /tmp/tmp.kQs4YxWFpL/util/scripting-engines/trace-event-perl.o CC /tmp/tmp.kQs4YxWFpL/util/intel-bts.o MKDIR /tmp/tmp.kQs4YxWFpL/util/scripting-engines/ CC /tmp/tmp.kQs4YxWFpL/util/intel-pt.o CC /tmp/tmp.kQs4YxWFpL/util/scripting-engines/trace-event-python.o CC /tmp/tmp.kQs4YxWFpL/util/arm-spe.o CC /tmp/tmp.kQs4YxWFpL/util/s390-cpumsf.o util/cs-etm-decoder/cs-etm-decoder.c:161:44: error: unknown type name ‘ocsd_ete_cfg’; did you mean ‘ocsd_stm_cfg’? 161 | ocsd_ete_cfg *config) | ^~~~~~~~~~~~ | ocsd_stm_cfg util/cs-etm-decoder/cs-etm-decoder.c: In function ‘cs_etm_decoder__create_etm_decoder’: util/cs-etm-decoder/cs-etm-decoder.c:620:9: error: unknown type name ‘ocsd_ete_cfg’; did you mean ‘ocsd_stm_cfg’? 620 | ocsd_ete_cfg trace_config_ete; | ^~~~~~~~~~~~ | ocsd_stm_cfg util/cs-etm-decoder/cs-etm-decoder.c:639:17: error: implicit declaration of function ‘cs_etm_decoder__gen_ete_config’; did you mean ‘cs_etm_decoder__gen_etmv4_config’? [-Werror=implicit-function-declaration] 639 | cs_etm_decoder__gen_ete_config(t_params, &trace_config_ete); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | cs_etm_decoder__gen_etmv4_config cc1: all warnings being treated as errors make[7]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:97: /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/cs-etm-decoder.o] Error 1 make[6]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:139: cs-etm-decoder] Error 2 make[6]: *** Waiting for unfinished jobs.... CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-decoder.o CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-insn-decoder.o LD /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/perf-in.o LD /tmp/tmp.kQs4YxWFpL/util/scripting-engines/perf-in.o LD /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/perf-in.o make[5]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:139: util] Error 2 make[4]: *** [Makefile.perf:658: /tmp/tmp.kQs4YxWFpL/perf-in.o] Error 2 rm /tmp/tmp.kQs4YxWFpL/dlfilters/dlfilter-test-api-v0.o make[3]: *** [Makefile.perf:238: sub-make] Error 2 make[2]: *** [Makefile:70: all] Error 2 make[1]: *** [tests/make:337: make_with_coresight_O] Error 1 make: *** [Makefile:103: build-test] Error 2 make: Leaving directory '/var/home/acme/git/perf/tools/perf' real 1m23.257s user 13m37.871s sys 2m53.438s ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$
Em Wed, Sep 01, 2021 at 01:07:41PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > > for a potentially user facing issue. If we add a new magic number in > > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > > > Applies cleanly to my tree, test building it now, holler if there is > > something that prevents it from being merged. > > I´m now trying to fix this up, I applied it using 'b4', so no patch > should have gone missing... So its probably related to: ⬢[acme@toolbox perf]$ rpm -qa | grep opencsd opencsd-1.0.0-1.fc34.x86_64 opencsd-devel-1.0.0-1.fc34.x86_64 ⬢[acme@toolbox perf]$ In which case the usual mechanism is to test if we have what is needed via tools/build/feature/test-_____.c, lemme check... - Arnaldo > ⬢[acme@toolbox perf]$ time make -C tools/perf build-test > make: Entering directory '/var/home/acme/git/perf/tools/perf' > - tarpkg: ./tests/perf-targz-src-pkg . > make_static: cd . && make LDFLAGS=-static NO_PERF_READ_VDSO32=1 NO_PERF_READ_VDSOX32=1 NO_JVMTI=1 -j24 DESTDIR=/tmp/tmp.tw23W3JC1W > make_with_gtk2: cd . && make GTK2=1 -j24 DESTDIR=/tmp/tmp.F7gN4e98pK > make_tags_O: cd . && make tags FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.tQVbhFdXKU DESTDIR=/tmp/tmp.1vbvWgUYUv > make_no_slang_O: cd . && make NO_SLANG=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.2L0POmKIip DESTDIR=/tmp/tmp.0qTYEQTY8e > make_no_demangle_O: cd . && make NO_DEMANGLE=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.Wh3kRYOFJo DESTDIR=/tmp/tmp.ih1nESGU6N > make_no_sdt_O: cd . && make NO_SDT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.zw3NugHqvZ DESTDIR=/tmp/tmp.li1bxbfYOZ > make_no_backtrace_O: cd . && make NO_BACKTRACE=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.66VxfiD04f DESTDIR=/tmp/tmp.PIgwBwGEZz > make_install_prefix_O: cd . && make install prefix=/tmp/krava FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.s6u85zKKjU DESTDIR=/tmp/tmp.2FJoF1mCRB > make_with_coresight_O: cd . && make CORESIGHT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.kQs4YxWFpL DESTDIR=/tmp/tmp.z93leAThcc > cd . && make CORESIGHT=1 FEATURES_DUMP=/var/home/acme/git/perf/tools/perf/BUILD_TEST_FEATURE_DUMP -j24 O=/tmp/tmp.kQs4YxWFpL DESTDIR=/tmp/tmp.z93leAThcc > BUILD: Doing 'make -j24' parallel build > HOSTCC /tmp/tmp.kQs4YxWFpL/fixdep.o > HOSTLD /tmp/tmp.kQs4YxWFpL/fixdep-in.o > LINK /tmp/tmp.kQs4YxWFpL/fixdep > Makefile.config:1038: No openjdk development package found, please install JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel > GEN /tmp/tmp.kQs4YxWFpL/common-cmds.h > CC /tmp/tmp.kQs4YxWFpL/exec-cmd.o > CC /tmp/tmp.kQs4YxWFpL/help.o > <SNIP> > CC /tmp/tmp.kQs4YxWFpL/util/auxtrace.o > MKDIR /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/ > CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-pkt-decoder.o > MKDIR /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/ > MKDIR /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/ > CC /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/arm-spe-pkt-decoder.o > CC /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/arm-spe-decoder.o > MKDIR /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/ > GEN /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/inat-tables.c > MKDIR /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/ > CC /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/cs-etm-decoder.o > CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-log.o > MKDIR /tmp/tmp.kQs4YxWFpL/util/scripting-engines/ > CC /tmp/tmp.kQs4YxWFpL/util/scripting-engines/trace-event-perl.o > CC /tmp/tmp.kQs4YxWFpL/util/intel-bts.o > MKDIR /tmp/tmp.kQs4YxWFpL/util/scripting-engines/ > CC /tmp/tmp.kQs4YxWFpL/util/intel-pt.o > CC /tmp/tmp.kQs4YxWFpL/util/scripting-engines/trace-event-python.o > CC /tmp/tmp.kQs4YxWFpL/util/arm-spe.o > CC /tmp/tmp.kQs4YxWFpL/util/s390-cpumsf.o > util/cs-etm-decoder/cs-etm-decoder.c:161:44: error: unknown type name ‘ocsd_ete_cfg’; did you mean ‘ocsd_stm_cfg’? > 161 | ocsd_ete_cfg *config) > | ^~~~~~~~~~~~ > | ocsd_stm_cfg > util/cs-etm-decoder/cs-etm-decoder.c: In function ‘cs_etm_decoder__create_etm_decoder’: > util/cs-etm-decoder/cs-etm-decoder.c:620:9: error: unknown type name ‘ocsd_ete_cfg’; did you mean ‘ocsd_stm_cfg’? > 620 | ocsd_ete_cfg trace_config_ete; > | ^~~~~~~~~~~~ > | ocsd_stm_cfg > util/cs-etm-decoder/cs-etm-decoder.c:639:17: error: implicit declaration of function ‘cs_etm_decoder__gen_ete_config’; did you mean ‘cs_etm_decoder__gen_etmv4_config’? [-Werror=implicit-function-declaration] > 639 | cs_etm_decoder__gen_ete_config(t_params, &trace_config_ete); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > | cs_etm_decoder__gen_etmv4_config > cc1: all warnings being treated as errors > make[7]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:97: /tmp/tmp.kQs4YxWFpL/util/cs-etm-decoder/cs-etm-decoder.o] Error 1 > make[6]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:139: cs-etm-decoder] Error 2 > make[6]: *** Waiting for unfinished jobs.... > CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-decoder.o > CC /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/intel-pt-insn-decoder.o > LD /tmp/tmp.kQs4YxWFpL/util/arm-spe-decoder/perf-in.o > LD /tmp/tmp.kQs4YxWFpL/util/scripting-engines/perf-in.o > LD /tmp/tmp.kQs4YxWFpL/util/intel-pt-decoder/perf-in.o > make[5]: *** [/var/home/acme/git/perf/tools/build/Makefile.build:139: util] Error 2 > make[4]: *** [Makefile.perf:658: /tmp/tmp.kQs4YxWFpL/perf-in.o] Error 2 > rm /tmp/tmp.kQs4YxWFpL/dlfilters/dlfilter-test-api-v0.o > make[3]: *** [Makefile.perf:238: sub-make] Error 2 > make[2]: *** [Makefile:70: all] Error 2 > make[1]: *** [tests/make:337: make_with_coresight_O] Error 1 > make: *** [Makefile:103: build-test] Error 2 > make: Leaving directory '/var/home/acme/git/perf/tools/perf' > > real 1m23.257s > user 13m37.871s > sys 2m53.438s > ⬢[acme@toolbox perf]$ > ⬢[acme@toolbox perf]$ > >
Em Wed, Sep 01, 2021 at 01:16:56PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Sep 01, 2021 at 01:07:41PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > > > for a potentially user facing issue. If we add a new magic number in > > > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > > > > > Applies cleanly to my tree, test building it now, holler if there is > > > something that prevents it from being merged. > > > > I´m now trying to fix this up, I applied it using 'b4', so no patch > > should have gone missing... > > So its probably related to: > > ⬢[acme@toolbox perf]$ rpm -qa | grep opencsd > opencsd-1.0.0-1.fc34.x86_64 > opencsd-devel-1.0.0-1.fc34.x86_64 > ⬢[acme@toolbox perf]$ > > In which case the usual mechanism is to test if we have what is needed > via tools/build/feature/test-_____.c, lemme check... There is a test and it fails, of course: ⬢[acme@toolbox perf]$ cat /tmp/build/perf/feature/test-libopencsd.make.output test-libopencsd.c:9:2: error: #error "OpenCSD >= 1.1.1 is required" 9 | #error "OpenCSD >= 1.1.1 is required" | ^~~~~ ⬢[acme@toolbox perf]$ But the fact that I ask for CORESIGHT=1 should have the build fail then, i.e. if one explicitely asks for a feature and it can't be built, fail the whole build. - Arnaldo
Em Wed, Sep 01, 2021 at 01:25:37PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Wed, Sep 01, 2021 at 01:16:56PM -0300, Arnaldo Carvalho de Melo escreveu: > > Em Wed, Sep 01, 2021 at 01:07:41PM -0300, Arnaldo Carvalho de Melo escreveu: > > > Em Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo escreveu: > > > > Applies cleanly to my tree, test building it now, holler if there is > > > > something that prevents it from being merged. > > > I´m now trying to fix this up, I applied it using 'b4', so no patch > > > should have gone missing... > > So its probably related to: > > ⬢[acme@toolbox perf]$ rpm -qa | grep opencsd > > opencsd-1.0.0-1.fc34.x86_64 > > opencsd-devel-1.0.0-1.fc34.x86_64 > > ⬢[acme@toolbox perf]$ > > In which case the usual mechanism is to test if we have what is needed > > via tools/build/feature/test-_____.c, lemme check... > There is a test and it fails, of course: > ⬢[acme@toolbox perf]$ cat /tmp/build/perf/feature/test-libopencsd.make.output > test-libopencsd.c:9:2: error: #error "OpenCSD >= 1.1.1 is required" > 9 | #error "OpenCSD >= 1.1.1 is required" > | ^~~~~ > ⬢[acme@toolbox perf]$ > But the fact that I ask for CORESIGHT=1 should have the build fail then, > i.e. if one explicitely asks for a feature and it can't be built, fail > the whole build. So after uninstalling the libopencsd that comes with fedora 34 and cloning the upstream OpenCSD git repo, building it and installing in /usr/local/ it seems to work as expected: ⬢[acme@toolbox perf]$ rm -rf /tmp/build/perf ; mkdir -p /tmp/build/perf ; ⬢[acme@toolbox perf]$ make O=/tmp/build/perf VF=1 CORESIGHT=1 O=/tmp/build/perf -C tools/perf install-bin |& grep -i opencsd ... libopencsd: [ on ] ⬢[acme@toolbox perf]$ cat /tmp/build/perf/feature/test-libopencsd.make.output ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$ ldd ~/bin/perf | grep opencsd libopencsd_c_api.so.1 => not found ⬢[acme@toolbox perf]$ export LD_LIBRARY_PATH=/usr/local/lib ⬢[acme@toolbox perf]$ ldd ~/bin/perf | grep opencsd libopencsd_c_api.so.1 => /usr/local/lib/libopencsd_c_api.so.1 (0x00007f839e8b2000) libopencsd.so.1 => /usr/local/lib/libopencsd.so.1 (0x00007f839da3c000) ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$ ⬢[acme@toolbox perf]$ ldd /tmp/build/perf/feature/test-libopencsd.bin linux-vdso.so.1 (0x00007ffd669b3000) libopencsd_c_api.so.1 => /usr/local/lib/libopencsd_c_api.so.1 (0x00007fe608b8c000) libopencsd.so.1 => /usr/local/lib/libopencsd.so.1 (0x00007fe608af5000) libc.so.6 => /lib64/libc.so.6 (0x00007fe60891e000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe6086ff000) libm.so.6 => /lib64/libm.so.6 (0x00007fe6085bb000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe6085a0000) /lib64/ld-linux-x86-64.so.2 (0x00007fe608ba2000) ⬢[acme@toolbox perf]$ ls -la /usr/local/lib/libopencsd* -rw-r--r--. 1 root root 1641364 Sep 1 13:41 /usr/local/lib/libopencsd.a -rw-r--r--. 1 root root 168022 Sep 1 13:41 /usr/local/lib/libopencsd_c_api.a lrwxrwxrwx. 1 root root 21 Sep 1 13:41 /usr/local/lib/libopencsd_c_api.so -> libopencsd_c_api.so.1 lrwxrwxrwx. 1 root root 25 Sep 1 13:41 /usr/local/lib/libopencsd_c_api.so.1 -> libopencsd_c_api.so.1.1.1 -rw-r--r--. 1 root root 104968 Sep 1 13:41 /usr/local/lib/libopencsd_c_api.so.1.1.1 lrwxrwxrwx. 1 root root 15 Sep 1 13:41 /usr/local/lib/libopencsd.so -> libopencsd.so.1 lrwxrwxrwx. 1 root root 19 Sep 1 13:41 /usr/local/lib/libopencsd.so.1 -> libopencsd.so.1.1.1 -rw-r--r--. 1 root root 762432 Sep 1 13:41 /usr/local/lib/libopencsd.so.1.1.1 ⬢[acme@toolbox perf]$ This doesn't explain that 'make -C tools/perf build-test' error, perhaps it is reusing the feature dump (feature detection), done without CORESIGHT=1, when building with CORESIGHT=1 :-\ Anyway, please consider making the build fail when CORESIGHT=1 is passed explicitely and that tools/build/feature-libopencsd.c feature test fails instead of silently building the tool _without_ the explicitely asked for feature. Thanks, - Arnaldo
Hi Arnaldo, On Wed, Sep 01, 2021 at 01:49:51PM -0300, Arnaldo Carvalho de Melo wrote: [...] > This doesn't explain that 'make -C tools/perf build-test' error, perhaps > it is reusing the feature dump (feature detection), done without > CORESIGHT=1, when building with CORESIGHT=1 :-\ > > Anyway, please consider making the build fail when CORESIGHT=1 is passed > explicitely and that tools/build/feature-libopencsd.c feature test fails > instead of silently building the tool _without_ the explicitely asked > for feature. Sorry for inconvenience. I have sent a patch to allow the build to report error when detect feature failure for libopencsd [1]. It's obviously that there have another issue with 'make -C tools/perf build-test' which should not build with option 'CORESIGHT=1' by default. Please let me know if you want me to follow this issue or not. Thanks, Leo [1] https://lists.linaro.org/pipermail/coresight/2021-September/006967.html p.s. I didn't use the patch linkage from lore.kernel.org, seems the server is down when I try to fetch link from it.
Hi Arnaldo, On Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > for a potentially user facing issue. If we add a new magic number in > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > Applies cleanly to my tree, test building it now, holler if there is > something that prevents it from being merged. Have you already merged this? If so than let it be. Otherwise please hold off as I'd like to take a look, something I intend on doing next week. Thanks, Mathieu > - Arnaldo > > > > --- > > > tools/perf/util/cs-etm.c | 5 +++++ > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c > > > index 788ad5a099f6..5b276bdb96a6 100644 > > > --- a/tools/perf/util/cs-etm.c > > > +++ b/tools/perf/util/cs-etm.c > > > @@ -2973,6 +2973,11 @@ int cs_etm__process_auxtrace_info(union perf_event *event, > > > > > > /* ETE shares first part of metadata with ETMv4 */ > > > trcidr_idx = CS_ETMV4_TRCTRACEIDR; > > > + } else { > > > + ui__error("CS ETM Trace: Unrecognised magic number %#"PRIx64". File could be from a newer version of perf.\n", > > > + ptr[i]); > > > + err = -EINVAL; > > > + goto err_free_metadata; > > > } > > > > > > if (!metadata[j]) { > > > -- > > > 2.28.0 > > > > > -- > > - Arnaldo
Em Thu, Sep 02, 2021 at 11:48:51AM -0600, Mathieu Poirier escreveu: > Hi Arnaldo, > > On Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > > for a potentially user facing issue. If we add a new magic number in > > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > > > Applies cleanly to my tree, test building it now, holler if there is > > something that prevents it from being merged. > > Have you already merged this? > > If so than let it be. Otherwise please hold off as I'd like to take a look, > something I intend on doing next week. Ok, I can remove them from my local branch, but this may make this miss the v5.15 merge window, please advise. - Arnaldo
On Thu, 2 Sept 2021 at 12:19, Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > Em Thu, Sep 02, 2021 at 11:48:51AM -0600, Mathieu Poirier escreveu: > > Hi Arnaldo, > > > > On Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > > > for a potentially user facing issue. If we add a new magic number in > > > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > > > > > Applies cleanly to my tree, test building it now, holler if there is > > > something that prevents it from being merged. > > > > Have you already merged this? > > > > If so than let it be. Otherwise please hold off as I'd like to take a look, > > something I intend on doing next week. > > Ok, I can remove them from my local branch, but this may make this miss > the v5.15 merge window, please advise. > Nah, leave it in your branch and proceed for this merge window. > - Arnaldo
Reviewed-by: Mike Leach <mike.leach@linaro.org> On Thu, 2 Sept 2021 at 20:22, Mathieu Poirier <mathieu.poirier@linaro.org> wrote: > > On Thu, 2 Sept 2021 at 12:19, Arnaldo Carvalho de Melo <acme@kernel.org> wrote: > > > > Em Thu, Sep 02, 2021 at 11:48:51AM -0600, Mathieu Poirier escreveu: > > > Hi Arnaldo, > > > > > > On Wed, Sep 01, 2021 at 12:54:34PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Tue, Aug 24, 2021 at 04:36:15PM +0800, Leo Yan escreveu: > > > > > On Fri, Aug 06, 2021 at 02:41:09PM +0100, James Clark wrote: > > > > > > Currently perf reports "Cannot allocate memory" which isn't very helpful > > > > > > for a potentially user facing issue. If we add a new magic number in > > > > > > the future, perf will be able to report unrecognised magic numbers. > > > > > > > > > > > > Signed-off-by: James Clark <james.clark@arm.com> > > > > > > > > > > Reviewed-by: Leo Yan <leo.yan@linaro.org> > > > > > > > > Applies cleanly to my tree, test building it now, holler if there is > > > > something that prevents it from being merged. > > > > > > Have you already merged this? > > > > > > If so than let it be. Otherwise please hold off as I'd like to take a look, > > > something I intend on doing next week. > > > > Ok, I can remove them from my local branch, but this may make this miss > > the v5.15 merge window, please advise. > > > > Nah, leave it in your branch and proceed for this merge window. > > > - Arnaldo -- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c index 788ad5a099f6..5b276bdb96a6 100644 --- a/tools/perf/util/cs-etm.c +++ b/tools/perf/util/cs-etm.c @@ -2973,6 +2973,11 @@ int cs_etm__process_auxtrace_info(union perf_event *event, /* ETE shares first part of metadata with ETMv4 */ trcidr_idx = CS_ETMV4_TRCTRACEIDR; + } else { + ui__error("CS ETM Trace: Unrecognised magic number %#"PRIx64". File could be from a newer version of perf.\n", + ptr[i]); + err = -EINVAL; + goto err_free_metadata; } if (!metadata[j]) {
Currently perf reports "Cannot allocate memory" which isn't very helpful for a potentially user facing issue. If we add a new magic number in the future, perf will be able to report unrecognised magic numbers. Signed-off-by: James Clark <james.clark@arm.com> --- tools/perf/util/cs-etm.c | 5 +++++ 1 file changed, 5 insertions(+)