linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	linux-kernel@vger.kernel.org, acme@kernel.org,
	linuxppc-dev@lists.ozlabs.org
Cc: anton@ozlabs.org, ananth@in.ibm.com, dja@axtens.net,
	naveen.n.rao@linux.vnet.ibm.com, David.Laight@ACULAB.COM,
	Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Subject: Re: [PATCH v3 3/4] perf annotate: add powerpc support
Date: Fri, 8 Jul 2016 10:23:45 +0530	[thread overview]
Message-ID: <577F31D9.4050808@linux.vnet.ibm.com> (raw)
In-Reply-To: <87vb0j84fb.fsf@@concordia.ellerman.id.au>

Hi Michael,

On Wednesday 06 July 2016 03:38 PM, Michael Ellerman wrote:
> Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com> writes:
>
>> 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?
> Yeah I understand you can't show an arrow.
>
> I guess it could just be an unterminated arrow? But I'm not sure if
> that's easy to do with the way the UI is constructed. eg. something
> like:
>
>      ld      r12,0(r12)
>      mtctr   r12
>      bctrl	------------------>
>      ld      r3,-32704(r2)
>
> But that's just an idea.

I've sent v4 which enables annotate for bctr' instructions.

for 'bctr', it will show down arrow(indicate jump) and 'bctrl' will show
right arrow(indicate call). But no navigation options will be provided.
By pressing Enter key on that, message will be shown that like
"Invalid target"

Please review it.

>> 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.
> Agreed.
>
>> 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.
> OK.
>
> Maybe what I'm asking for is an enhancement and can be done later.
>
>>> It doesn't look like we have the opcode handy here? Could we get it somehow?
>>> That would make this a *lot* more robust.
>> objdump prints machine code, but I don't know how difficult that would
>> be to parse to get opcode.
> Normal objdump -d output includes the opcode, eg:
>
> c00000000000886c:       2c 2c 00 00     cmpdi   r12,0
>                          ^^^^^^^^^^^
>
> The only thing you need to know is the endian and you can reconstruct
> the raw instruction.
>
> Then you can just decode the opcode, see how we do it in the kernel with
> eg. instr_is_relative_branch().

I'm sorry. I was thinking that you wants to show opcodes with perf
annotate. But you were asking to use opcode instead of parsing
instructions.

This looks like rewrite parsing code. I don't know whether there is any
library already available for this which we can directly use. I'm thinking
about this.

- Ravi

> cheers
>

  parent reply	other threads:[~2016-07-08  4:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-30  6:14 [PATCH v3 0/4] perf annotate: Enable cross arch annotate Ravi Bangoria
2016-06-30  6:14 ` [PATCH v3 1/4] perf: Utility function to fetch arch Ravi Bangoria
2016-07-01  6:46   ` [tip:perf/core] perf evsel: " tip-bot for Ravi Bangoria
2016-06-30  6:14 ` [PATCH v3 2/4] perf annotate: Enable cross arch annotate Ravi Bangoria
2016-06-30  6:14 ` [PATCH v3 3/4] perf annotate: add powerpc support Ravi Bangoria
2016-06-30  6:21   ` Michael Ellerman
2016-07-01  8:43     ` Ravi Bangoria
2016-07-01 12:48       ` Balbir Singh
2016-07-01 13:30         ` Ravi Bangoria
2016-07-05  1:28       ` Ravi Bangoria
     [not found]       ` <87vb0j84fb.fsf@@concordia.ellerman.id.au>
2016-07-08  4:53         ` Ravi Bangoria [this message]
     [not found]           ` <87zipsmsyd.fsf@@concordia.ellerman.id.au>
2016-07-12  2:21             ` Ravi Bangoria
2016-07-12  2:39               ` Arnaldo Carvalho de Melo
     [not found]                 ` <87eg6ym1gq.fsf@@concordia.ellerman.id.au>
2016-07-13  9:29                   ` Ravi Bangoria
2016-06-30  6:14 ` [PATCH v3 4/4] perf: Define macro for normalized arch names Ravi Bangoria

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=577F31D9.4050808@linux.vnet.ibm.com \
    --to=ravi.bangoria@linux.vnet.ibm.com \
    --cc=David.Laight@ACULAB.COM \
    --cc=acme@kernel.org \
    --cc=ananth@in.ibm.com \
    --cc=anton@ozlabs.org \
    --cc=dja@axtens.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).