From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: jolsa@kernel.org, adrian.hunter@intel.com, irogers@google.com,
namhyung@kernel.org, segher@kernel.crashing.org,
christophe.leroy@csgroup.eu, linux-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
akanksha@linux.ibm.com, maddy@linux.ibm.com, kjain@linux.ibm.com,
hbathini@linux.ibm.com, disgoel@linux.vnet.ibm.com
Subject: Re: [PATCH V8 03/15] tools/perf: Update TYPE_STATE_MAX_REGS to include max of regs in powerpc
Date: Tue, 23 Jul 2024 16:06:28 -0300 [thread overview]
Message-ID: <Zp__NN2SrLvqn423@x1> (raw)
In-Reply-To: <20240718084358.72242-4-atrajeev@linux.vnet.ibm.com>
On Thu, Jul 18, 2024 at 02:13:46PM +0530, Athira Rajeev wrote:
> TYPE_STATE_MAX_REGS is arch-dependent. Currently this is defined
> to be 16. While checking if reg is valid using has_reg_type,
> max value is checked using TYPE_STATE_MAX_REGS value. Define
> this conditionally for powerpc.
So what would happen if I get a perf.data file on a powerpc system and
then try to do data-type profiling on a x86 system?
I'm processing this now, but please consider fixing this up in some
other fashion, I think we have support for collecting registers in a way
that perf.data has all that is needed for us to print them in a cross
arch way, no?
I see there is the FIXME there, ok.
- Arnaldo
> Reviewed-and-tested-by: Kajol Jain <kjain@linux.ibm.com>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Athira Rajeev<atrajeev@linux.vnet.ibm.com>
> ---
> tools/perf/util/annotate-data.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/perf/util/annotate-data.h b/tools/perf/util/annotate-data.h
> index 6fe8ee8b8410..992b7ce4bd11 100644
> --- a/tools/perf/util/annotate-data.h
> +++ b/tools/perf/util/annotate-data.h
> @@ -189,7 +189,11 @@ struct type_state_stack {
> };
>
> /* FIXME: This should be arch-dependent */
> +#ifdef __powerpc__
> +#define TYPE_STATE_MAX_REGS 32
> +#else
> #define TYPE_STATE_MAX_REGS 16
> +#endif
>
> /*
> * State table to maintain type info in each register and stack location.
> --
> 2.43.0
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
Cc: irogers@google.com, disgoel@linux.vnet.ibm.com,
maddy@linux.ibm.com, kjain@linux.ibm.com,
adrian.hunter@intel.com, christophe.leroy@csgroup.eu,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
jolsa@kernel.org, namhyung@kernel.org, akanksha@linux.ibm.com,
linuxppc-dev@lists.ozlabs.org, hbathini@linux.ibm.com
Subject: Re: [PATCH V8 03/15] tools/perf: Update TYPE_STATE_MAX_REGS to include max of regs in powerpc
Date: Tue, 23 Jul 2024 16:06:28 -0300 [thread overview]
Message-ID: <Zp__NN2SrLvqn423@x1> (raw)
In-Reply-To: <20240718084358.72242-4-atrajeev@linux.vnet.ibm.com>
On Thu, Jul 18, 2024 at 02:13:46PM +0530, Athira Rajeev wrote:
> TYPE_STATE_MAX_REGS is arch-dependent. Currently this is defined
> to be 16. While checking if reg is valid using has_reg_type,
> max value is checked using TYPE_STATE_MAX_REGS value. Define
> this conditionally for powerpc.
So what would happen if I get a perf.data file on a powerpc system and
then try to do data-type profiling on a x86 system?
I'm processing this now, but please consider fixing this up in some
other fashion, I think we have support for collecting registers in a way
that perf.data has all that is needed for us to print them in a cross
arch way, no?
I see there is the FIXME there, ok.
- Arnaldo
> Reviewed-and-tested-by: Kajol Jain <kjain@linux.ibm.com>
> Reviewed-by: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Athira Rajeev<atrajeev@linux.vnet.ibm.com>
> ---
> tools/perf/util/annotate-data.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/perf/util/annotate-data.h b/tools/perf/util/annotate-data.h
> index 6fe8ee8b8410..992b7ce4bd11 100644
> --- a/tools/perf/util/annotate-data.h
> +++ b/tools/perf/util/annotate-data.h
> @@ -189,7 +189,11 @@ struct type_state_stack {
> };
>
> /* FIXME: This should be arch-dependent */
> +#ifdef __powerpc__
> +#define TYPE_STATE_MAX_REGS 32
> +#else
> #define TYPE_STATE_MAX_REGS 16
> +#endif
>
> /*
> * State table to maintain type info in each register and stack location.
> --
> 2.43.0
next prev parent reply other threads:[~2024-07-23 19:06 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 8:43 [PATCH V8 00/15] Add data type profiling support for powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 01/15] tools/perf: Move the data structures related to register type to header file Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 02/15] tools/perf: Add "update_insn_state" callback function to handle arch specific instruction tracking Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 03/15] tools/perf: Update TYPE_STATE_MAX_REGS to include max of regs in powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-23 19:06 ` Arnaldo Carvalho de Melo [this message]
2024-07-23 19:06 ` Arnaldo Carvalho de Melo
2024-07-24 5:38 ` Athira Rajeev
2024-07-24 5:38 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 04/15] tools/perf: Add disasm_line__parse to parse raw instruction for powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-23 19:14 ` Arnaldo Carvalho de Melo
2024-07-23 19:14 ` Arnaldo Carvalho de Melo
2024-07-24 5:38 ` Athira Rajeev
2024-07-24 5:38 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 05/15] tools/perf: Add support to capture and parse raw instruction in powerpc using dso__data_read_offset utility Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 06/15] tools/perf: Update parameters for reg extract functions to use raw instruction on powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 07/15] tools/perf: Add parse function for memory instructions in powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 08/15] tools/perf: Add support to identify memory instructions of opcode 31 " Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 09/15] tools/perf: Add some of the arithmetic instructions to support instruction tracking " Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 10/15] tools/perf: Add more instructions for instruction tracking Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 11/15] tools/perf: Update instruction tracking for powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 12/15] tools/perf: Make capstone_init non-static so that it can be used during symbol disassemble Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 13/15] tools/perf: Use capstone_init and remove open_capstone_handle from disasm.c Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-18 8:43 ` [PATCH V8 14/15] tools/perf: Add support to use libcapstone in powerpc Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-24 21:00 ` Arnaldo Carvalho de Melo
2024-07-24 21:00 ` Arnaldo Carvalho de Melo
2024-07-26 12:35 ` Athira Rajeev
2024-07-26 12:35 ` Athira Rajeev
2024-07-31 13:51 ` kernel test robot
2024-07-31 13:51 ` kernel test robot
2024-07-18 8:43 ` [PATCH V8 15/15] tools/perf: Set instruction name to be used with insn-stat when using raw instruction Athira Rajeev
2024-07-18 8:43 ` Athira Rajeev
2024-07-23 20:07 ` [PATCH V8 00/15] Add data type profiling support for powerpc Arnaldo Carvalho de Melo
2024-07-23 20:07 ` Arnaldo Carvalho de Melo
2024-07-24 7:59 ` Athira Rajeev
2024-07-24 7:59 ` 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=Zp__NN2SrLvqn423@x1 \
--to=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akanksha@linux.ibm.com \
--cc=atrajeev@linux.vnet.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=disgoel@linux.vnet.ibm.com \
--cc=hbathini@linux.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 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.