All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	acme@kernel.org, peterz@infradead.org, mingo@redhat.com,
	alexander.shishkin@linux.intel.com, treeze.taeung@gmail.com,
	naveen.n.rao@linux.vnet.ibm.com, markus@trippelsdorf.de,
	chris.ryder@arm.com, pawel.moll@arm.com, mhiramat@kernel.org,
	jolsa@kernel.org, mpe@ellerman.id.au, hemant@linux.vnet.ibm.com,
	namhyung@kernel.org,
	Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Subject: Re: [PATCH v5 2/7] perf annotate: Add cross arch annotate support
Date: Fri, 19 Aug 2016 17:03:38 +0530	[thread overview]
Message-ID: <57B6EE92.6050200@linux.vnet.ibm.com> (raw)
In-Reply-To: <20160819104821.GL1041@n2100.armlinux.org.uk>



On Friday 19 August 2016 04:18 PM, Russell King - ARM Linux wrote:
> On Fri, Aug 19, 2016 at 04:09:51PM +0530, Ravi Bangoria wrote:
>> Thanks Russell for reviewing.
>>
>> On Friday 19 August 2016 01:20 PM, Russell King - ARM Linux wrote:
>>> On Fri, Aug 19, 2016 at 10:59:01AM +0530, Ravi Bangoria wrote:
>>>> -static struct ins instructions[] = {
>>>> +static struct ins instructions_x86[] = {
>>>>  	{ .name = "add",   .ops  = &mov_ops, },
>>>>  	{ .name = "addl",  .ops  = &mov_ops, },
>>>>  	{ .name = "addq",  .ops  = &mov_ops, },
>>>>  	{ .name = "addw",  .ops  = &mov_ops, },
>>>>  	{ .name = "and",   .ops  = &mov_ops, },
>>>> -#ifdef __arm__
>>>> -	{ .name = "b",     .ops  = &jump_ops, }, // might also be a call
>>>> -	{ .name = "bcc",   .ops  = &jump_ops, },
>>>> -	{ .name = "bcs",   .ops  = &jump_ops, },
>>>> -	{ .name = "beq",   .ops  = &jump_ops, },
>>>> -	{ .name = "bge",   .ops  = &jump_ops, },
>>>> -	{ .name = "bgt",   .ops  = &jump_ops, },
>>>> -	{ .name = "bhi",   .ops  = &jump_ops, },
>>>> -	{ .name = "bl",    .ops  = &call_ops, },
>>>> -	{ .name = "bls",   .ops  = &jump_ops, },
>>>> -	{ .name = "blt",   .ops  = &jump_ops, },
>>>> -	{ .name = "blx",   .ops  = &call_ops, },
>>>> -	{ .name = "bne",   .ops  = &jump_ops, },
>>>> -#endif
>>> Notice that ARM includes a lot of other instructions from this table,
>>> not just those above.
>>>
>>>>  	{ .name = "bts",   .ops  = &mov_ops, },
>>>>  	{ .name = "call",  .ops  = &call_ops, },
>>>>  	{ .name = "callq", .ops  = &call_ops, },
>>>> @@ -456,6 +444,21 @@ static struct ins instructions[] = {
>>>>  	{ .name = "retq",  .ops  = &ret_ops, },
>>>>  };
>>>>  
>>>> +static struct ins instructions_arm[] = {
>>>> +	{ .name = "b",     .ops  = &jump_ops, }, /* might also be a call */
>>>> +	{ .name = "bcc",   .ops  = &jump_ops, },
>>>> +	{ .name = "bcs",   .ops  = &jump_ops, },
>>>> +	{ .name = "beq",   .ops  = &jump_ops, },
>>>> +	{ .name = "bge",   .ops  = &jump_ops, },
>>>> +	{ .name = "bgt",   .ops  = &jump_ops, },
>>>> +	{ .name = "bhi",   .ops  = &jump_ops, },
>>>> +	{ .name = "bl",    .ops  = &call_ops, },
>>>> +	{ .name = "bls",   .ops  = &jump_ops, },
>>>> +	{ .name = "blt",   .ops  = &jump_ops, },
>>>> +	{ .name = "blx",   .ops  = &call_ops, },
>>>> +	{ .name = "bne",   .ops  = &jump_ops, },
>>>> +};
>>>> +
>>> ...
>>>> +	if (!strcmp(norm_arch, NORM_X86)) {
>>>> +		instructions = instructions_x86;
>>>> +		nmemb = ARRAY_SIZE(instructions_x86);
>>>> +	} else if (!strcmp(norm_arch, NORM_ARM)) {
>>>> +		instructions = instructions_arm;
>>>> +		nmemb = ARRAY_SIZE(instructions_arm);
>>> But these changes result in _only_ the ones that were in the #if __arm__
>>> being matched.  This is wrong.
>>>
>>> If we want to go that way, we need to add _all_ arm instructions to
>>> instructions_arm, not just those within the #if.
>> Yes, I've mentioned same in cover letter as well.
>>
>> Can I add all x86 instructions for arm as well? If not, can you please
>> provide a list of arm instructions that needs to be added here.
> If it were me doing a change like this, I'd be trying to preserve the
> current behaviour to avoid causing regressions, which would mean
> ensuring that all the instructions that were visible before the change
> remain visible after the change, even those which are obviously x86
> specific but were still in the table anyway.  It then becomes a cleanup
> matter later to remove those which aren't relevent, rather than having
> to chase around wondering why the tool broke.
>
> I'm afraid I don't have time to look at this (I'm chasing regressions
> and bugs in the kernel) so I'd suggest you try to avoid causing
> regressions in this tool...
>

Yes Russell, Fair point. Will send a next series.

-Ravi

  reply	other threads:[~2016-08-19 11:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-19  5:28 [PATCH v5 0/7] perf: Cross arch annotate + few miscellaneous fixes Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 1/7] perf: Define macro for normalized arch names Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 2/7] perf annotate: Add cross arch annotate support Ravi Bangoria
2016-08-19  7:50   ` Russell King - ARM Linux
2016-08-19 10:39     ` Ravi Bangoria
2016-08-19 10:48       ` Russell King - ARM Linux
2016-08-19 11:33         ` Ravi Bangoria [this message]
2016-08-19  5:29 ` [PATCH v5 3/7] perf annotate: Add support for powerpc Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 4/7] perf annotate: Do not ignore call instruction with indirect target Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 5/7] perf annotate: Show raw form for jump " Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 6/7] perf annotate: Support jump instruction with target as second operand Ravi Bangoria
2016-08-19  5:29 ` [PATCH v5 7/7] perf annotate: Fix jump target outside of function address range 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=57B6EE92.6050200@linux.vnet.ibm.com \
    --to=ravi.bangoria@linux.vnet.ibm.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=chris.ryder@arm.com \
    --cc=hemant@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=markus@trippelsdorf.de \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=namhyung@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=pawel.moll@arm.com \
    --cc=peterz@infradead.org \
    --cc=treeze.taeung@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.