| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <f1561c30-8b77-4ba5-964f-012b1e11cd2b@linaro.org>
Date: Thu, 18 Jul 2024 15:30:36 +0100
From: James Clark <james.clark@...aro.org>
To: Mike Leach <mike.leach@...aro.org>
Cc: coresight@...ts.linaro.org, suzuki.poulose@....com,
gankulkarni@...amperecomputing.com, leo.yan@...ux.dev,
anshuman.khandual@....com,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-stm32@...md-mailman.stormreply.com, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v5 07/17] perf: cs-etm: Print queue number in raw trace
dump
On 18/07/2024 2:25 pm, Mike Leach wrote:
> Hi James
>
> On Fri, 12 Jul 2024 at 11:22, James Clark <james.clark@...aro.org> wrote:
>>
>> From: James Clark <james.clark@....com>
>>
>> Now that we have overlapping trace IDs it's also useful to know what the
>> queue number is to be able to distinguish the source of the trace so
>> print it inline.
>>
>
> Not sure queue number is meaningful to anyone other than someone
> debugging the etm decode in perf. Perhaps cpu number?
It's more than just for debugging Perf, anyone who was previously
reading the raw trace would probably have grepped for, or be looking at
the "ID:" field. Now that doesn't identify trace from a single source
anymore, due to the overlapping IDs. Same applies if you want to process
the output in some way per-line.
With ETE technically it is CPU number, but I didn't want to name it like
that because it's overloaded: With ETM it's the "collection CPU" which
would be too misleading to label as CPU, and in per-thread mode it's
always 0 and not a CPU at all.
Although I suppose it's already labeled as CPU on the
PERF_RECORD_AUXTRACE output, and this just duplicates that so it should
be called CPU. Maybe it is ok to drop this one because the info already
exists in the PERF_RECORD_AUXTRACE output.
>
> Moreover - other additional debugging in the trace output is
> controlled with build options.
> See:-
> Makefile.config -> ifdef CSTRACE_RAW,
> thence:-
> #ifdef CS_DEBUG_RAW in cs-etm-decoder.c
>
> which adds in the raw byte data from the trace dump.
>
> Could we make this addtional info dependent on either the standard
> DEBUG macro, or an additional build macro.
>
>
What about behind the verbose argument to Perf?
>
>> Signed-off-by: James Clark <james.clark@....com>
>> Signed-off-by: James Clark <james.clark@...aro.org>
>> ---
>> tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 4 ++--
>> tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 2 +-
>> tools/perf/util/cs-etm.c | 7 ++++---
>> 3 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> index d49c3e9c7c21..b78ef0262135 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.c
>> @@ -41,7 +41,7 @@ const u32 INSTR_PER_NS = 10;
>>
>> struct cs_etm_decoder {
>> void *data;
>> - void (*packet_printer)(const char *msg);
>> + void (*packet_printer)(const char *msg, void *data);
>> bool suppress_printing;
>> dcd_tree_handle_t dcd_tree;
>> cs_etm_mem_cb_type mem_access;
>> @@ -202,7 +202,7 @@ static void cs_etm_decoder__print_str_cb(const void *p_context,
>> const struct cs_etm_decoder *decoder = p_context;
>>
>> if (p_context && str_len && !decoder->suppress_printing)
>> - decoder->packet_printer(msg);
>> + decoder->packet_printer(msg, decoder->data);
>> }
>>
>> static int
>> diff --git a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> index 272c2efe78ee..12c782fa6db2 100644
>> --- a/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> +++ b/tools/perf/util/cs-etm-decoder/cs-etm-decoder.h
>> @@ -60,7 +60,7 @@ struct cs_etm_trace_params {
>>
>> struct cs_etm_decoder_params {
>> int operation;
>> - void (*packet_printer)(const char *msg);
>> + void (*packet_printer)(const char *msg, void *data);
>> cs_etm_mem_cb_type mem_acc_cb;
>> bool formatted;
>> bool fsyncs;
>> diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
>> index 87e983da19be..49fadf46f42b 100644
>> --- a/tools/perf/util/cs-etm.c
>> +++ b/tools/perf/util/cs-etm.c
>> @@ -762,15 +762,16 @@ static void cs_etm__packet_swap(struct cs_etm_auxtrace *etm,
>> }
>> }
>>
>> -static void cs_etm__packet_dump(const char *pkt_string)
>> +static void cs_etm__packet_dump(const char *pkt_string, void *data)
>> {
>> const char *color = PERF_COLOR_BLUE;
>> int len = strlen(pkt_string);
>> + struct cs_etm_queue *etmq = data;
>>
>> if (len && (pkt_string[len-1] == '\n'))
>> - color_fprintf(stdout, color, " %s", pkt_string);
>> + color_fprintf(stdout, color, " Qnr:%d; %s", etmq->queue_nr, pkt_string);
>> else
>> - color_fprintf(stdout, color, " %s\n", pkt_string);
>> + color_fprintf(stdout, color, " Qnr:%d; %s\n", etmq->queue_nr, pkt_string);
>>
>> fflush(stdout);
>> }
>> --
>> 2.34.1
>>
>
> Mike
> --
> Mike Leach
> Principal Engineer, ARM Ltd.
> Manchester Design Centre. UK
Powered by blists - more mailing lists