[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aLs_BuzNJZt6Wl2g@google.com>
Date: Fri, 5 Sep 2025 12:50:30 -0700
From: Namhyung Kim <namhyung@...nel.org>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Zecheng Li <zecheng@...gle.com>, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>,
Masami Hiramatsu <mhiramat@...nel.org>,
Xu Liu <xliuprof@...gle.com>, linux-perf-users@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 01/10] perf dwarf-aux: Use signed variable types in
match_var_offset
On Wed, Sep 03, 2025 at 07:05:23PM -0300, Arnaldo Carvalho de Melo wrote:
> On Wed, Sep 03, 2025 at 12:49:49PM -0300, Arnaldo Carvalho de Melo wrote:
> > On Wed, Aug 27, 2025 at 11:52:02PM -0700, Namhyung Kim wrote:
> > > On Mon, Aug 25, 2025 at 07:54:03PM +0000, Zecheng Li wrote:
> > > > match_var_offset compares address offsets to determine if an access
> > > > falls within a variable's bounds. The offsets involved for those
> > > > relative to base registers from DW_OP_breg can be negative.
>
> > > > The current implementation uses unsigned types (u64) for these offsets,
> > > > which rejects almost all negative values.
>
> > > Right, I thought it cannot get negative offsets except for stack access
> > > (e.g. fbreg). But it turns out that container_of() trick can generate
> > > them with optimizing compilers.
>
> > > > Change the signature of match_var_offset to use signed types (s64). This
> > > > ensures correct behavior when addr_offset or addr_type are negative.
>
> > > > Signed-off-by: Zecheng Li <zecheng@...gle.com>
>
> > > I've confirmed it produced slightly better results on my test sets.
>
> > > Reviewed-by: Namhyung Kim <namhyung@...nel.org>
>
> > Cherry picked this first patch to make a bit of progress in the
> > perf-tools-next front.
>
> It is in perf-tools-next/perf-tools-next now (this first reviewed one):
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/log/?h=perf-tools-next
Thanks for doing that. Please pick up the patch 2 and 3 as well.
Namhyung
Powered by blists - more mailing lists