On Wed, Sep 07, 2022 at 01:14:52AM -0700, Namhyung Kim wrote:
On Wed, Sep 7, 2022 at 1:09 AM Jiri Olsa <olsajiri@xxxxxxxxx> wrote:
On Wed, Sep 07, 2022 at 01:19:32PM +0800, Xing Zhengjun wrote:
On 9/7/2022 12:50 PM, Namhyung Kim wrote:
Hello,
On Tue, Sep 6, 2022 at 7:49 PM Xing Zhengjun
<zhengjun.xing@xxxxxxxxxxxxxxx> wrote:
Hi,
On 9/1/2022 12:23 AM, Arnaldo Carvalho de Melo wrote:
Em Wed, Aug 31, 2022 at 09:02:46AM -0700, Ian Rogers escreveu:
On Wed, Aug 31, 2022 at 5:40 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote:
Hongtao Yu reported problem when displaying uregs in perf script
for system wide perf.data:
# perf script -F uregs | head -10
Samples for 'dummy:HG' event do not have UREGS attribute set. Cannot print 'uregs' field.
The problem is the extra dummy event added for system wide,
which does not have proper sample_type setup.
Skipping attr check completely for dummy event as suggested
by Namhyung, because it does not have any samples anyway.
Reported-by: Hongtao Yu <hoy@xxxxxx>
Suggested-by: Namhyung Kim <namhyung@xxxxxxxxxx>
Signed-off-by: Jiri Olsa <jolsa@xxxxxxxxxx>
Acked-by: Ian Rogers <irogers@xxxxxxxxxx>
Thanks, applied to perf/urgent.
- Arnaldo
I have met a similar issue on hybrid systems such as ADL, I apply the
patch, and it works OK for the normal mode.
# ./perf record --intr-regs=di,r8,dx,cx -e
br_inst_retired.near_call:p -c 1000 --per-thread true
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.024 MB perf.data (25 samples) ]
# ./perf script -F iregs |head -5
ABI:2 CX:0xffff90e19d024ed8 DX:0x1 DI:0xffff90e19d024ed8
R8:0xffffba5e437e7b30
ABI:2 CX:0x7f5239783000 DX:0x80000000 DI:0xffff90e1801eea00
R8:0x71
ABI:2 CX:0x40 DX:0x60 DI:0xffffffff9fde5ab8 R8:0x40
ABI:2 CX:0x0 DX:0xffffffffffffffff DI:0xffff90e1877408e8
R8:0x1
ABI:2 CX:0xcc0 DX:0x1 DI:0xffff90e187d17c60 R8:0x40
But the issue still happened when running the test in the pipe mode. In
the pipe mode, it calls process_attr() which still checks the attr for
the dummy event, so the issue happened.
# ./perf record -o - --intr-regs=di,r8,dx,cx -e
br_inst_retired.near_call:p -c 1000 --per-thread true 2>/dev/null|./perf
script -F iregs |head -5
Samples for 'dummy:HG' event do not have IREGS attribute set. Cannot
print 'iregs' field.
0x120 [0x90]: failed to process type: 64
I have one test patch which can fix the pipe mode issue.
./perf record -o - --intr-regs=di,r8,dx,cx -e
br_inst_retired.near_call:p -c 1000 --per-thread true 2>/dev/null|./perf
script -F iregs |head -5
ABI:2 CX:0xffff90e18119e278 DX:0x0 DI:0xffff90e18119f858
R8:0xffff90e18119e278
ABI:2 CX:0x0 DX:0x1 DI:0xfffffa2844a91580 R8:0x402
ABI:2 CX:0x0 DX:0x0 DI:0x100cca R8:0x0
ABI:2 CX:0x0 DX:0x0 DI:0xffffffff9e997ca5 R8:0x0
ABI:2 CX:0x113ce8000 DX:0xffff90e198f46600
DI:0xffff90e189de8000 R8:0x290
Fixes: b91e5492f9d7 ("perf record: Add a dummy event on hybrid systems
to collect metadata records")
Signed-off-by: Zhengjun Xing <zhengjun.xing@xxxxxxxxxxxxxxx>
---
tools/perf/builtin-script.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 9152e3e45b69..2d863cdb19fe 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -2429,6 +2429,8 @@ static int process_attr(struct perf_tool *tool,
union perf_event *event,
}
if (evsel->core.attr.sample_type) {
+ if (evsel__is_dummy_event(evsel))
+ return 0;
Maybe we can move this into evsel__check_attr().
Thanks,
Namhyung
Yes, the following changes in evsel__check_attr() can fix both normal and
pipe mode issues, Otherwise, we have to patch everywhere when
evsel__check_attr() is called.
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 13580a9c50b8..fb76e3191858 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -451,6 +451,9 @@ static int evsel__check_attr(struct evsel *evsel, struct
perf_session *session)
allow_user_set = perf_header__has_feat(&session->header,
HEADER_AUXTRACE);
+ if (evsel__is_dummy_event(evsel))
+ allow_user_set = true;
+
hm, do you need to pass allow_user_set to UREGS check then?
Well.. actually I thought we can simply return 0 for a dummy event.
true :-)
jirka