Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230627181030.95608-1-irogers@google.com> <20230627181030.95608-14-irogers@google.com>
 <CAM9d7cjxrNTOUGxmTAycko_Gn_uY5aX8cBWTa-jrhLoc-Bur1g@mail.gmail.com> <CAP-5=fWdOQR0MvpJM2aW5Cc=GS86h2Kmh9zD2k5--K=8BNyVgw@mail.gmail.com>
In-Reply-To: <CAP-5=fWdOQR0MvpJM2aW5Cc=GS86h2Kmh9zD2k5--K=8BNyVgw@mail.gmail.com>
From:   Namhyung Kim <namhyung@kernel.org>
Date:   Sat, 1 Jul 2023 11:43:24 -0700
Message-ID: <CAM9d7ciBPUiM0QhfP=_EJXqZ=SgEkHii0Jc2J-MBkZr7k1wKUA@mail.gmail.com>
Subject: Re: [PATCH v2 13/13] perf parse-events: Remove ABORT_ON
To:     Ian Rogers <irogers@google.com>
Cc:     Peter Zijlstra <peterz@infradead.org>,
        Ingo Molnar <mingo@redhat.com>,
        Arnaldo Carvalho de Melo <acme@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Alexander Shishkin <alexander.shishkin@linux.intel.com>,
        Jiri Olsa <jolsa@kernel.org>,
        Adrian Hunter <adrian.hunter@intel.com>,
        Athira Rajeev <atrajeev@linux.vnet.ibm.com>,
        Kan Liang <kan.liang@linux.intel.com>,
        linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
        bpf@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Fri, Jun 30, 2023 at 8:14 AM Ian Rogers <irogers@google.com> wrote:
>
> On Thu, Jun 29, 2023 at 2:49 PM Namhyung Kim <namhyung@kernel.org> wrote:
> >
> > On Tue, Jun 27, 2023 at 11:11 AM Ian Rogers <irogers@google.com> wrote:
> > >
> > > Prefer informative messages rather than none with ABORT_ON. Document
> > > one failure mode and add an error message for another.
> > >
> > > Signed-off-by: Ian Rogers <irogers@google.com>
> > > ---
> > >  tools/perf/util/parse-events.y | 22 ++++++++++++++--------
> > >  1 file changed, 14 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
> > > index 844646752462..454577f7aff6 100644
> > > --- a/tools/perf/util/parse-events.y
> > > +++ b/tools/perf/util/parse-events.y
> > > @@ -22,12 +22,6 @@
> > >
> > >  void parse_events_error(YYLTYPE *loc, void *parse_state, void *scanner, char const *msg);
> > >
> > > -#define ABORT_ON(val) \
> > > -do { \
> > > -       if (val) \
> > > -               YYABORT; \
> > > -} while (0)
> > > -
> > >  #define PE_ABORT(val) \
> > >  do { \
> > >         if (val == -ENOMEM) \
> > > @@ -618,7 +612,9 @@ PE_RAW opt_event_config
> > >                 YYNOMEM;
> > >         errno = 0;
> > >         num = strtoull($1 + 1, NULL, 16);
> > > -       ABORT_ON(errno);
> > > +       /* Given the lexer will only give [a-fA-F0-9]+ a failure here should be impossible. */
> > > +       if (errno)
> > > +               YYABORT;
> > >         free($1);
> > >         err = parse_events_add_numeric(_parse_state, list, PERF_TYPE_RAW, num, $2,
> > >                                        /*wildcard=*/false);
> > > @@ -978,7 +974,17 @@ PE_VALUE PE_ARRAY_RANGE PE_VALUE
> > >  {
> > >         struct parse_events_array array;
> > >
> > > -       ABORT_ON($3 < $1);
> > > +       if ($3 < $1) {
> > > +               struct parse_events_state *parse_state = _parse_state;
> > > +               struct parse_events_error *error = parse_state->error;
> > > +               char *err_str;
> > > +
> > > +               if (asprintf(&err_str, "Expected '%ld' to be less-than '%ld'", $3, $1) < 0)
> >
> > Isn't it to be "greater-than or equal" ?
>
> I think the order is right. From the man page:
>
>        When  successful,  these  functions return the number of bytes printed,
>        just like sprintf(3).  If memory allocation wasn't  possible,  or  some
>        other error occurs, these functions will return -1, and the contents of
>        strp are undefined.
>
> So here we need to catch -1 and ensure strp (&err_str) is NULL before
> passing it to parse_events_error__handle.

Oh, I meant the message not the condition in the if statement.
It seems it aborts if $3 < $1, then it expects $3 >= $1 in the
normal condition, right?

Thanks,
Namhyung