From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752411AbcGANbt (ORCPT ); Fri, 1 Jul 2016 09:31:49 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:50864 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750702AbcGANbr (ORCPT ); Fri, 1 Jul 2016 09:31:47 -0400 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: ravi.bangoria@linux.vnet.ibm.com Subject: Re: [PATCH v3 3/4] perf annotate: add powerpc support To: Balbir Singh , Michael Ellerman , linux-kernel@vger.kernel.org, acme@kernel.org, linuxppc-dev@lists.ozlabs.org References: <1467267262-4589-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com> <1467267262-4589-4-git-send-email-ravi.bangoria@linux.vnet.ibm.com> <1467267714.7296.6.camel@ellerman.id.au> <57762D2A.9040103@linux.vnet.ibm.com> <1467377311.12509.3.camel@gmail.com> Cc: ananth@in.ibm.com, David.Laight@ACULAB.COM, naveen.n.rao@linux.vnet.ibm.com, dja@axtens.net, Ravi Bangoria From: Ravi Bangoria Date: Fri, 1 Jul 2016 19:00:33 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1467377311.12509.3.camel@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16070113-0028-0000-0000-00000514B05B X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16070113-0029-0000-0000-00002D29C203 Message-Id: <57767079.50205@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-01_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607010136 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Balbir, On Friday 01 July 2016 06:18 PM, Balbir Singh wrote: > On Fri, 2016-07-01 at 14:13 +0530, Ravi Bangoria wrote: >> Thanks Michael for your suggestion. >> >> On Thursday 30 June 2016 11:51 AM, Michael Ellerman wrote: >>> >>> On Thu, 2016-06-30 at 11:44 +0530, Ravi Bangoria wrote: >>>> >>>> diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c >>>> index 36a5825..b87eac7 100644 >>>> --- a/tools/perf/util/annotate.c >>>> +++ b/tools/perf/util/annotate.c >>>> @@ -476,6 +481,125 @@ static int ins__cmp(const void *a, const void *b) >>> ... >>>> >>>> + >>>> +static struct ins *ins__find_powerpc(const char *name) >>>> +{ >>>> + int i; >>>> + struct ins *ins; >>>> + struct ins_ops *ops; >>>> + static struct instructions_powerpc head; >>>> + static bool list_initialized; >>>> + >>>> + /* >>>> + * - Interested only if instruction starts with 'b'. >>>> + * - Few start with 'b', but aren't branch instructions. >>>> + * - Let's also ignore instructions involving 'ctr' and >>>> + * 'tar' since target branch addresses for those can't >>>> + * be determined statically. >>>> + */ >>>> + if (name[0] != 'b' || >>>> + !strncmp(name, "bcd", 3) || >>>> + !strncmp(name, "brinc", 5) || >>>> + !strncmp(name, "bper", 4) || >>>> + strstr(name, "ctr") || >>>> + strstr(name, "tar")) >>>> + return NULL; >>> It would be good if 'bctr' was at least recognised as a branch, even if we >>> can't determine the target. They are very common. >> We can not show arrow for this since we don't know the target location. >> can you please suggest how you intends perf to display bctr? >> >> bctr can be classified into two variants -- 'bctr' and 'bctrl'. >> >> 'bctr' will be considered as jump instruction but jump__parse() won't >> be able to find any target location and hence it will set target to >> UINT64_MAX which transform 'bctr' to 'bctr UINT64_MAX'. This >> looks misleading. >> >> bctrl will be considered as call instruction but call_parse() won't >> be able to find any target function and hence it won't show any >> navigation arrow for this instruction. Which is same as filter it >> beforehand. >> > The target location and function are in the counter. Can't we add > this to instruction ops? Is it a major change to add it? Of course we can add it. What I mean is we can not determine target location statically by parsing objdump output. For example, consider snippet: objdump output: c000000000143848: lwarx r8,0,r10 c00000000014384c: addic r8,r8,1 c000000000143850: stwcx. r8,0,r10 c000000000143854: bne- c000000000143848 <.rcu_idle_exit+0x58> corresponding perf annotate output: 58: lwarx r8,0,r10 addic r8,r8,1 stwcx. r8,0,r10 bne- 58 tui will show up arrow before 'bne- 58' instruction, that indicate it as a jump instruction. When we focus on 'bne- 58' instruction, arrow will span from that instruction to instruction with 58th offset( lwarx ). By pressing Enter, it will jump focus to the target. In case of 'bctr', we can not determine target location statically and hence we can not provide any navigation options. Same for 'bctrl' as well. Please correct me if I misunderstood anything. -Ravi > > Balbir Singh. >