[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200826113354.GB753783@krava>
Date: Wed, 26 Aug 2020 13:33:54 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Ian Rogers <irogers@...gle.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
Kajol Jain <kjain@...ux.ibm.com>,
Andi Kleen <ak@...ux.intel.com>,
Jin Yao <yao.jin@...ux.intel.com>,
Kan Liang <kan.liang@...ux.intel.com>,
Adrian Hunter <adrian.hunter@...el.com>,
Leo Yan <leo.yan@...aro.org>, linux-kernel@...r.kernel.org,
Stephane Eranian <eranian@...gle.com>
Subject: Re: [PATCH 1/2] perf expr: Force encapsulation on expr_id_data
On Tue, Aug 25, 2020 at 09:29:09PM -0700, Ian Rogers wrote:
> This patch resolves some undefined behavior where variables in
> expr_id_data were accessed (for debugging) without being defined. To
> better enforce the tagged union behavior, the struct is moved into
> expr.c and accessors provided. Tag values (kinds) are explicitly
> identified.
>
> Signed-off-by: Ian Rogers <irogers@...gle.com>
> ---
> tools/perf/util/expr.c | 64 ++++++++++++++++++++++++++++++-----
> tools/perf/util/expr.h | 17 +++-------
> tools/perf/util/expr.y | 2 +-
> tools/perf/util/metricgroup.c | 4 +--
> 4 files changed, 62 insertions(+), 25 deletions(-)
>
> diff --git a/tools/perf/util/expr.c b/tools/perf/util/expr.c
> index 53482ef53c41..1ca0992db86b 100644
> --- a/tools/perf/util/expr.c
> +++ b/tools/perf/util/expr.c
> @@ -17,6 +17,25 @@
> extern int expr_debug;
> #endif
>
> +struct expr_id_data {
> + union {
> + double val;
> + struct {
> + double val;
> + const char *metric_name;
> + const char *metric_expr;
> + } ref;
> + struct expr_id *parent;
> + };
> +
> + enum {
> + EXPR_ID_DATA__VALUE,
> + EXPR_ID_DATA__REF,
> + EXPR_ID_DATA__REF_VALUE,
> + EXPR_ID_DATA__PARENT,
> + } kind;
I like that, it's more clear than current state ;-)
could you still put a small comment for each enum above,
as a hint what it's used for?
thanks,
jirka
Powered by blists - more mailing lists