Hi,
>From the little information in this mail, this looks like an issue
with how the version of perf you have is interacting with the OpenCSD
library. An ocsdError will usually be generated if the library
detects input errors in configuration or data being passed to it.
ocsdErrors in general should provide a code + string - though output
could be being suppressed by perf. I would follow Leo's suggestion to
see if you can spot the library call from the backtrace that causes
the issue.
Regards
Mike
On Mon, 21 Oct 2019 at 06:39, Leo Yan <leo.yan(a)linaro.org> wrote:
>
> Hi Bharat,
>
> [ + Mike ]
>
> On Mon, Oct 21, 2019 at 05:28:54AM +0000, Bharat Bhushan wrote:
> > Hi Leo, Mathieu,
> >
> > I found your email-id from linux git-log, Please ignore if you are not right person.
> >
> > I am using perf for hwtracing (coresight).
> >
> >
> > $perf record -C 0 -e cs_etm/@tmc_etr0/u ./test
> > Couldn't synthesize bpf events.
> > [ perf record: Woken up 1 times to write data ]
> > [ perf record: Captured and wrote 0.124 MB perf.data ]
> >
> > $ perf report
> > terminate called after throwing an instance of 'ocsdError'
> > terminate called recursively
> > Aborted (core dumped)
> >
> >
> > $ perf report -v
> > build id event received for [kernel.kallsyms]: 473d5d96eceb209a58f19ec8f3e4f74891d49c9f
> > build id event received for /usr/lib/systemd/systemd: 16460ffcbc368221e1e71c587c059a44497eb3de
> > build id event received for /usr/lib/aarch64-linux-gnu/libudev.so.1.6.12: bf0152a1c65039afe462800eb834190830a5c8d2
> > .
> > <snip>
> > .
> > build id event received for /usr/lib/aarch64-linux-gnu/libdw-0.176.so: ad9dc3a40b2f39629fcc70ad2bb931d75f89b748
> > build id event received for /usr/lib/aarch64-linux-gnu/libelf-0.176.so: 0b36ddcd158758dcb8356713eff8fe12c1326d21
> > build id event received for /usr/lib/libopencsd_c_api.so.0.12.0: 84a1cf9a8b6efb9670b902d87118f05c81856b53
> > Aborted (core dumped)
> > terminate called after throwing an instance of 'ocsdError'
> > terminate called recursively
> > root@ubuntu:~#
> >
> >
> > Also I added prints in "perf" source code before calling and opencsd library function (please find attached file) and no prints observed.
> > I am not sure why we are getting "ocsdError".
> >
> > Can you please point what's wrong I am doing.
>
> I think the error is reported internally in OpenCSD rather than the
> failure in perf tool.
>
> And you could see there have core dump file, suggest you could to
> use the core dump file with gdb to dump the backtrace. Then this can
> help us to find the flow for the failure.
>
> I loop Mike since this issue is more likely related with decoder.
>
> Thanks,
> Leo Yan
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
This patch series is to address the issue for synthesizing instruction
samples, especially when the instruction sample period is small enough,
the current logic cannot synthesize multiple instruction samples within
one instruction range packet.
To fix this issue, patch 0001 avoids to reset the last branches for
every instruction sample; if reset the last branches when every time
generate instruction sample, then the later samples in the same range
packet cannot use the last branches anymore.
Patch 0002 is the main patch to fix the logic for synthesizing
instruction samples; it allows to handle different instruction periods.
Patch 0003 is an optimization for copying last branches; it only copies
last branches once if the instruction samples share the same last
branches.
Patch 0004 is a minor fix for unsigned variable comparison to zero.
To verify my changing for synthesizing instruction samples, I added
some logs in the code, and reviewed the output log manually for
instuctions samples. The below commands are tested on DB410c board:
# perf script --itrace=i2
# perf script --itrace=i2il16
# perf inject --itrace=i2il16 -i perf.data -o perf.data.new
# perf inject --itrace=i100il16 -i perf.data -o perf.data.new
Changes from v1:
* Rebased patch set on perf/core branch with latest commit 9fec3cd5fa4a
("perf map: Check if the map still has some refcounts on exit").
Leo Yan (4):
perf cs-etm: Continuously record last branches
perf cs-etm: Correct synthesizing instruction samples
perf cs-etm: Optimize copying last branches
perf cs-etm: Fix unsigned variable comparison to zero
tools/perf/util/cs-etm.c | 137 ++++++++++++++++++++++++++++++++-------
1 file changed, 115 insertions(+), 22 deletions(-)
--
2.17.1
This patch series is to address the issue for synthesizing instruction
samples, especially when the instruction sample period is small enough,
the current logic cannot synthesize multiple instruction samples within
one instruction range packet.
To fix this issue, patch 0001 avoids to reset the last branches for
every instruction sample; if reset the last branches when every time
generate instruction sample, then the later samples in the same range
packet cannot use the last branches anymore.
Patch 0002 is the main patch to fix the logic for synthesizing
instruction samples; it allows to handle different instruction periods.
Patch 0003 is an optimization for copying last branches; it only copies
last branches once if the instruction samples share the same last
branches.
Patch 0004 is a minor fix for unsigned variable comparison to zero.
To verify my changing for synthesizing instruction samples, I added
some logs in the code, and reviewed the output log manually for
instuctions samples. The below commands are tested on DB410c board:
# perf script --itrace=i2
# perf script --itrace=i2li16
# perf inject --itrace=i2il16 -i perf.data -o perf.data.new
# perf inject --itrace=i100il16 -i perf.data -o perf.data.new
Leo Yan (4):
perf cs-etm: Continuously record last branches
perf cs-etm: Correct synthesizing instruction samples
perf cs-etm: Optimize copying last branches
perf cs-etm: Fix unsigned variable comparison to zero
tools/perf/util/cs-etm.c | 137 ++++++++++++++++++++++++++++++++-------
1 file changed, 115 insertions(+), 22 deletions(-)
--
2.17.1
