mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christophe Leroy <christophe.leroy@csgroup.eu>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
	"acme@kernel.org" <acme@kernel.org>,
	"jolsa@kernel.org" <jolsa@kernel.org>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"irogers@google.com" <irogers@google.com>,
	"namhyung@kernel.org" <namhyung@kernel.org>,
	"segher@kernel.crashing.org" <segher@kernel.crashing.org>
Cc: "linux-perf-users@vger.kernel.org"
	<linux-perf-users@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"maddy@linux.ibm.com" <maddy@linux.ibm.com>,
	"kjain@linux.ibm.com" <kjain@linux.ibm.com>,
	"disgoel@linux.vnet.ibm.com" <disgoel@linux.vnet.ibm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"akanksha@linux.ibm.com" <akanksha@linux.ibm.com>
Subject: Re: [PATCH V2 4/9] tools/perf: Add support to capture and parse raw instruction in objdump
Date: Tue, 7 May 2024 09:35:22 +0000	[thread overview]
Message-ID: <f2efdb9d-e636-4678-b492-83d3a28d8134@csgroup.eu> (raw)
In-Reply-To: <20240506121906.76639-5-atrajeev@linux.vnet.ibm.com>



Le 06/05/2024 à 14:19, Athira Rajeev a écrit :
> Add support to capture and parse raw instruction in objdump.

What's the purpose of using 'objdump' for reading raw instructions ? 
Can't they be read directly without invoking 'objdump' ? It looks odd to 
me to use objdump to provide readable text and then parse it back.

> Currently, the perf tool infrastructure uses "--no-show-raw-insn" option
> with "objdump" while disassemble. Example from powerpc with this option
> for an instruction address is:

Yes and that makes sense because the purpose of objdump is to provide 
human readable annotations, not to perform automated analysis. Am I 
missing something ?

> 
> Snippet from:
> objdump  --start-address=<address> --stop-address=<address>  -d --no-show-raw-insn -C <vmlinux>
> 
> c0000000010224b4:	lwz     r10,0(r9)
> 
> This line "lwz r10,0(r9)" is parsed to extract instruction name,
> registers names and offset. Also to find whether there is a memory
> reference in the operands, "memory_ref_char" field of objdump is used.
> For x86, "(" is used as memory_ref_char to tackle instructions of the
> form "mov  (%rax), %rcx".
> 
> In case of powerpc, not all instructions using "(" are the only memory
> instructions. Example, above instruction can also be of extended form (X
> form) "lwzx r10,0,r19". Inorder to easy identify the instruction category
> and extract the source/target registers, patch adds support to use raw
> instruction. With raw instruction, macros are added to extract opcode
> and register fields.
> 
> "struct ins_operands" and "struct ins" is updated to carry opcode and
> raw instruction binary code (raw_insn). Function "disasm_line__parse"
> is updated to fill the raw instruction hex value and opcode in newly
> added fields. There is no changes in existing code paths, which parses
> the disassembled code. The architecture using the instruction name and
> present approach is not altered. Since this approach targets powerpc,
> the macro implementation is added for powerpc as of now.
> 
> Example:
> representation using --show-raw-insn in objdump gives result:
> 
> 38 01 81 e8     ld      r4,312(r1)
> 
> Here "38 01 81 e8" is the raw instruction representation. In powerpc,
> this translates to instruction form: "ld RT,DS(RA)" and binary code
> as:
> _____________________________________
> | 58 |  RT  |  RA |      DS       | |
> -------------------------------------
> 0    6     11    16              30 31
> 
> Function "disasm_line__parse" is updated to capture:
> 
> line:    38 01 81 e8     ld      r4,312(r1)
> opcode and raw instruction "38 01 81 e8"
> Raw instruction is used later to extract the reg/offset fields.
> 
> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
> ---

  parent reply	other threads:[~2024-05-07  9:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-06 12:18 [PATCH V2 0/9] Add data type profiling support for powerpc Athira Rajeev
2024-05-06 12:18 ` [PATCH V2 1/9] tools/perf: Move the data structures related to register type to header file Athira Rajeev
2024-05-06 12:18 ` [PATCH V2 2/9] tools/perf: Add "update_insn_state" callback function to handle arch specific instruction tracking Athira Rajeev
2024-05-06 12:19 ` [PATCH V2 3/9] tools/perf: Fix a comment about multi_regs in extract_reg_offset function Athira Rajeev
2024-05-07  4:40   ` Namhyung Kim
2024-05-07 14:52     ` Arnaldo Carvalho de Melo
2024-05-06 12:19 ` [PATCH V2 4/9] tools/perf: Add support to capture and parse raw instruction in objdump Athira Rajeev
2024-05-07  4:57   ` Namhyung Kim
2024-05-07  9:35   ` Christophe Leroy [this message]
2024-05-09 17:26     ` Athira Rajeev
2024-05-09 20:55       ` Namhyung Kim
2024-05-10 14:26       ` Arnaldo Carvalho de Melo
2024-05-22 13:58         ` Athira Rajeev
2024-05-06 12:19 ` [PATCH V2 5/9] tools/perf: Update parameters for reg extract functions to use raw instruction on powerpc Athira Rajeev
2024-05-07  9:48   ` Christophe Leroy
2024-05-22 14:06     ` Athira Rajeev
2024-05-06 12:19 ` [PATCH V2 6/9] tools/perf: Update instruction tracking for powerpc Athira Rajeev
2024-05-07  9:52   ` Christophe Leroy
2024-05-23 13:58     ` Athira Rajeev
2024-05-06 12:19 ` [PATCH V2 7/9] tools/perf: Update instruction tracking with add instruction Athira Rajeev
2024-05-07  9:58   ` Christophe Leroy
2024-05-23 13:55     ` Athira Rajeev
2024-05-06 12:19 ` [PATCH V2 8/9] tools/perf: Add support to find global register variables using find_data_type_global_reg Athira Rajeev
2024-05-07 10:03   ` Christophe Leroy
2024-05-24 12:17     ` Athira Rajeev
2024-05-24 12:47       ` Christophe Leroy
2024-05-06 12:19 ` [PATCH V2 9/9] tools/perf: Add support for global_die to capture name of variable in case of register defined variable Athira Rajeev
2024-05-07  4:39 ` [PATCH V2 0/9] Add data type profiling support for powerpc Namhyung Kim
2024-05-13  7:32   ` Athira Rajeev

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=f2efdb9d-e636-4678-b492-83d3a28d8134@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=akanksha@linux.ibm.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=disgoel@linux.vnet.ibm.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=kjain@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=maddy@linux.ibm.com \
    --cc=namhyung@kernel.org \
    --cc=segher@kernel.crashing.org \
    /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

all inboxes | Powered by JetHome®