Re: [PATCH 2/4] perf: Print branch stack entry type in --dump-raw-trace

From: James Clark <james.clark@arm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	acme@kernel.org, linux-perf-users@vger.kernel.org
Cc: german.gomez@arm.com, leo.yan@linaro.com,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] perf: Print branch stack entry type in --dump-raw-trace
Date: Tue, 8 Mar 2022 11:58:27 +0000	[thread overview]
Message-ID: <a4429c3b-91b2-12f5-f0c6-c8db16d0c9f8@arm.com> (raw)
In-Reply-To: <fb9717bb-735a-88d9-254d-0e7b2f7209f2@arm.com>

On 08/03/2022 04:29, Anshuman Khandual wrote:
> 
> 
> On 3/7/22 22:49, James Clark wrote:
>> This can help with debugging issues. It only prints when -j save_type
>> is used otherwise an empty string is printed.
> 
> Specifying events with PERF_SAMPLE_BRANCH_CALL_STACK flag explicitly might
> be better along with '-j save_type'.
> 
>>
>> Before the change:
>>
>>   101603801707130 0xa70 [0x630]: PERF_RECORD_SAMPLE(IP, 0x2): 1108/1108: 0xffff9c1df24c period: 10694 addr: 0
>>   ... branch stack: nr:64
>>   .....  0: 0000ffff9c26029c -> 0000ffff9c26f340 0 cycles  P   0
>>   .....  1: 0000ffff9c2601bc -> 0000ffff9c26f340 0 cycles  P   0
>>
>> After the change:
>>
>>   101603801707130 0xa70 [0x630]: PERF_RECORD_SAMPLE(IP, 0x2): 1108/1108: 0xffff9c1df24c period: 10694 addr: 0
>>   ... branch stack: nr:64
>>   .....  0: 0000ffff9c26029c -> 0000ffff9c26f340 0 cycles  P   0 CALL
>>   .....  1: 0000ffff9c2601bc -> 0000ffff9c26f340 0 cycles  P   0 IND_CALL
>>
>> Signed-off-by: James Clark <james.clark@arm.com>
>> ---
>>  tools/perf/util/session.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
>> index f54282d5c648..3b8dfe603e50 100644
>> --- a/tools/perf/util/session.c
>> +++ b/tools/perf/util/session.c
>> @@ -1159,14 +1159,15 @@ static void branch_stack__printf(struct perf_sample *sample, bool callstack)
>>  		struct branch_entry *e = &entries[i];
>>  
>>  		if (!callstack) {
>> -			printf("..... %2"PRIu64": %016" PRIx64 " -> %016" PRIx64 " %hu cycles %s%s%s%s %x\n",
>> +			printf("..... %2"PRIu64": %016" PRIx64 " -> %016" PRIx64 " %hu cycles %s%s%s%s %x %s\n",
>>  				i, e->from, e->to,
>>  				(unsigned short)e->flags.cycles,
>>  				e->flags.mispred ? "M" : " ",
>>  				e->flags.predicted ? "P" : " ",
>>  				e->flags.abort ? "A" : " ",
>>  				e->flags.in_tx ? "T" : " ",
>> -				(unsigned)e->flags.reserved);
>> +				(unsigned)e->flags.reserved,
>> +				e->flags.type ? branch_type_name(e->flags.type) : "");
>>  		} else {
>>  			printf("..... %2"PRIu64": %016" PRIx64 "\n",
>>  				i, i > 0 ? e->from : e->to);
> 
> LGTM but I am wondering whether this might affect existing tools ?

Only humans should be reading the -D output so I don't think so. The format is not very parseable anyway