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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a4429c3b-91b2-12f5-f0c6-c8db16d0c9f8@arm.com>
Date:   Tue, 8 Mar 2022 11:58:27 +0000
From:   James Clark <james.clark@....com>
To:     Anshuman Khandual <anshuman.khandual@....com>, acme@...nel.org,
        linux-perf-users@...r.kernel.org
Cc:     german.gomez@....com, leo.yan@...aro.com,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/4] perf: Print branch stack entry type in
 --dump-raw-trace



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@....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