Message-Id: <20241004233211.e3eecf45189f29d40d31d548@kernel.org>
Date: Fri, 4 Oct 2024 23:32:11 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Ian Rogers <irogers@...gle.com>
Cc: Namhyung Kim <namhyung@...nel.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, 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>, Jiri Olsa <jolsa@...nel.org>, Adrian
 Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>,
 John Garry <john.g.garry@...cle.com>, Will Deacon <will@...nel.org>, James
 Clark <james.clark@...aro.org>, Mike Leach <mike.leach@...aro.org>, Leo Yan
 <leo.yan@...ux.dev>, Guo Ren <guoren@...nel.org>, Paul Walmsley
 <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, Albert Ou
 <aou@...s.berkeley.edu>, Nick Terrell <terrelln@...com>, Guilherme Amadio
 <amadio@...too.org>, Changbin Du <changbin.du@...wei.com>,
 "Steinar H. Gunderson" <sesse@...gle.com>, Aditya Gupta
 <adityag@...ux.ibm.com>, Athira Rajeev <atrajeev@...ux.vnet.ibm.com>,
 Masahiro Yamada <masahiroy@...nel.org>, Huacai Chen
 <chenhuacai@...nel.org>, Bibo Mao <maobibo@...ngson.cn>, Kajol Jain
 <kjain@...ux.ibm.com>, Anup Patel <anup@...infault.org>, Shenlin Liang
 <liangshenlin@...incomputing.com>, Atish Patra <atishp@...osinc.com>,
 Oliver Upton <oliver.upton@...ux.dev>, Chen Pei <cp0613@...ux.alibaba.com>,
 Dima Kogan <dima@...retsauce.net>, Alexander Lobakin
 <aleksander.lobakin@...el.com>, "David S. Miller" <davem@...emloft.net>,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org, Yang Jihong
 <yangjihong@...edance.com>
Subject: Re: [PATCH v1 11/11] perf build: Rename PERF_HAVE_DWARF_REGS to
 PERF_HAVE_LIBDW_REGS

On Thu, 3 Oct 2024 17:58:13 -0700
Ian Rogers <irogers@...gle.com> wrote:

> On Thu, Oct 3, 2024 at 3:48 PM Namhyung Kim <namhyung@...nel.org> wrote:
> >
> > On Wed, Oct 02, 2024 at 07:27:16AM -0700, Ian Rogers wrote:
> > > On Wed, Oct 2, 2024 at 6:56 AM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > > >
> > > > On Tue, 1 Oct 2024 18:31:43 -0700
> > > > Ian Rogers <irogers@...gle.com> wrote:
> > > >
> > > > > On Tue, Oct 1, 2024 at 4:29 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > > > > >
> > > > > > On Tue, 1 Oct 2024 16:17:34 -0700
> > > > > > Ian Rogers <irogers@...gle.com> wrote:
> > > > > >
> > > > > > > On Tue, Oct 1, 2024 at 4:10 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 30, 2024 at 09:02:36PM -0700, Ian Rogers wrote:
> > > > > > > > > On Sat, Sep 28, 2024 at 7:35 PM Masami Hiramatsu <mhiramat@...nel.org> wrote:
> > > > > > > > > >
> > > > > > > > > > On Fri, 27 Sep 2024 11:15:21 -0700
> > > > > > > > > > Ian Rogers <irogers@...gle.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > On Fri, Sep 27, 2024 at 10:16 AM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Sep 26, 2024 at 12:55:18PM -0700, Ian Rogers wrote:
> > > > > > > > > > > > > On Thu, Sep 26, 2024 at 12:40 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Sep 26, 2024 at 05:47:16AM -0700, Ian Rogers wrote:
> > > > > > > > > > > > > > > On Wed, Sep 25, 2024 at 8:27 PM Namhyung Kim <namhyung@...nel.org> wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Sep 24, 2024 at 09:04:18AM -0700, Ian Rogers wrote:
> > > > > > > > > > > > > > > > > The name dwarf can imply libunwind support, whereas
> > > > > > > > > > > > > > > > > PERF_HAVE_DWARF_REGS is only enabled with libdw support. Rename to
> > > > > > > > > > > > > > > > > make it clearer there is a libdw connection.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > While it only covers libdw, I think the idea of this macro is whether
> > > > > > > > > > > > > > > > the arch has register mappings defined in DWARF standard.  So I think
> > > > > > > > > > > > > > > > it's better to keep the name for this case.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > How can the dwarf standard exist for an arch but not define registers?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I meant it's about the arch code in the perf tools to have the mapping,
> > > > > > > > > > > > > > not the DWARF standard itself.
> > > > > > > > > > > > >
> > > > > > > > > > > > > But we guard those definitions behind having libdw:
> > > > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/x86/Makefile?h=perf-tools-next#n3
> > > > > > > > > > > > > So we only have the regs if libdw is present, not if dwarf is in use
> > > > > > > > > > > > > for libunwind/libdw. Hence wanting to be specific that they are just a
> > > > > > > > > > > > > libdw and not a dwarf thing. Trying to use the regs in libunwind code
> > > > > > > > > > > > > would be broken. That could change but I wanted to make the code clear
> > > > > > > > > > > > > for the way things are at the moment.
> > > > > > > > > > > >
> > > > > > > > > > > > I understand your point but calling it LIBDW_REGS looks unnatural to me.
> > > > > > > > > > >
> > > > > > > > > > > I don't follow. Wouldn't it be unnatural to see PERF_HAVE_DWARF_REGS
> > > > > > > > > > > in libunwind code but you are to some how know that the code only had
> > > > > > > > > > > meaning if libdw was present? I don't like the implication that DWARF
> > > > > > > > > > > means LIBDW as throughout the code it doesn't. I think the name
> > > > > > > > > > > PERF_HAVE_LIBDW_REGS better captures how the code is, makes the code
> > > > > > > > > > > more intention revealing and so readable, etc.
> > > > > > > > > >
> > > > > > > > > > I agree with Namhyung this point. dwarf-regs is defined only by the
> > > > > > > > > > DWARF standard, not libdw only. The standard encode registers by a digit
> > > > > > > > > > number and the dwarf-regs decode the number to actual register name.
> > > > > > > > >
> > > > > > > > > The code is not making a statement about the DWARF standard, take arch/csky:
> > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/arch/csky/Makefile?h=perf-tools-next
> > > > > > > > > ```
> > > > > > > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > ifndef NO_DWARF
> > > > > > > > > PERF_HAVE_DWARF_REGS := 1
> > > > > > > > > endif
> > > > > > > > > ```
> > > > > > > > > in the patch series NO_DWARF becomes NO_LIBDW, so it is now:
> > > > > > > > > ```
> > > > > > > > > # SPDX-License-Identifier: GPL-2.0-only
> > > > > > > > > ifndef NO_LIBDW
> > > > > > > > > PERF_HAVE_DWARF_REGS := 1
> > > > > > > > > endif
> > > > > > > > > ```
> > > > > > > > > So the Makefile says that PERF_HAVE_DWARF_REGS is dependent on having
> > > > > > > > > NO_LIBDW, that is having libdw implies PERF_HAVE_DWARF_REGS is defined
> > > > > > > > > for csky.
> > > > > > > >
> > > > > > > > I think this is totally fine and we can change the condition later if
> > > > > > > > needed.
> > > > > > > >
> > > > > > > > After all, I don't think it's a big deal.  Let's just call DWARF
> > > > > > > > registers DWARF_REGS. :)
> > > > > > >
> > > > > > > The define is called PERF_HAVE_DWARF_REGS, notice the HAVE, but we're
> > > > > > > not setting it while supporting call-graph dwarf with libunwind. It is
> > > > > > > actively confusing.
> > > > > >
> > > > > > Does libunwind requires the dwarf regs? I think the dwarf regs information
> > > > > > is only needed for analyzing dwarf register assignment, not stack unwinding.
> > > > >
> > > > > So you are saying the #define is guarding a libdw feature?
> > > > > perf record/report --call-graph=dwarf is supported with either libdw
> > > > > or libunwind. The dwarf support in the tool may come from more sources
> > > > > hence wanting in this patch set to be clear what variable is guarding
> > > > > what. PERF_HAVE_DWARF_REGS is set to 1 for a specific set of
> > > > > architectures and only when libdw is present. The variable is saying
> > > > > that libdw supports the notion of registers needed for the #define
> > > > > HAVE_DWARF_SUPPORT that patch 9 in the series renamed to
> > > > > HAVE_LIBDW_SUPPORT. So I want the makefile variable
> > > > > PERF_HAVE_LIBDW_REGS to guard the #define HAVE_LIBDW_SUPPORT, rather
> > > > > than what is being argued by yourself and Namhyung that the #define
> > > > > HAVE_LIBDW_SUPPORT be guarded by a variable called
> > > > > PERF_HAVE_DWARF_REGS and that is only set when NO_LIBDW isn't set.
> > > >
> > > > It will be only used with the libdw, but I don't care.
> > > > "HAVE_DWARF_REG" (internal config, just indicates the arch implemented
> > > > feature) simply means there is `arch/XXX/util/dwarf-regs.c`.
> > > > Also the APIs provided by the dwarf-regs.c are still based on DWARF
> > > > standard, which defines registers by number like DW_OP_reg[0-31].
> > > > So the mapping of these suffix number and actual register must be
> > > > defined for each architecture.
> > > >
> > > > That is why I had introduced dwarf-regs.c and call it "dwarf"-regs.
> > > > Even if the implementation depends on libdw, this dwarf-regs.c is
> > > > still based on DWARF standard.
> > >
> > > You seem to be missing the point of the series which is to clean up
> > > inconsistencies where dwarf is used to mean libdw. Here we have libdw
> > > guarding a #define with DWARF in the name, it should have libdw in the
> > > name as the patch cleans up. This is a coding thing and not a dwarf
> > > specificatin thing.
> > >
> > > > > We've made a digression into the name dwarf for a reason I can't
> > > > > fathom, at best it is inconsistent. Having dwarf registers is like
> > > > > having a bright sun or numeric numbers, it is a truism (playing devils
> > > > > advocate maybe if there were an ELF file format for postscript we
> > > > > could have a dwarf specification without registers). Anyway, I'm
> > > > > trying to connect the dots that libdw support controls the libdw type
> > > > > variables and defines hence not wanting 10 out of 11 patches applied.
> > > >
> > > > Oh, wait, I think we can apply other patches. I just don't like this
> > > > patch. I think the other patches are good. But this is
> > >
> > > Then we are intentionally aiming to be inconsistent, with libdw
> > > meaning dwarf with a #define that just states a truism. Arguably the
> > > code is better with none of the series applied.
> >
> > I agree renaming libdw-specific parts.  But the register is for DWARF,
> > not libdw even if it's currently used by libdw only.   So I don't want
> > to rename it.
> 
> So your objection is that we have files called:
> tools/perf/arch/*/util/dwarf-regs.c
> and PERF_HAVE_DRWARF_REGS is an indication that this file exists. This
> file declares a single get_arch_regnum function. The building of the
> file after this series is:
> perf-util-$(CONFIG_LIBDW)     += dwarf-regs.o
> 
> My objection is that PERF_HAVE_DWARF_REGS is controlling the #define
> HAVE_LIBDW_SUPPORT, so dwarf (that can mean libunwind, libdw, etc.) is
> guarding having libdw which is backward and part of what this series
> has been trying to clean up.

OK.

> 
> If we rename tools/perf/arch/*/util/dwarf-regs.c to
> tools/perf/arch/*/util/libdw-helpers.c the PERF_HAVE_DWARF_REGS can be
> renamed to PERF_HAVE_LIBDW_HELPERS to align. Then
> PERF_HAVE_LIBDW_HELPERS guarding the #define PERF_HAVE_LIBDW makes
> sense to me and I think we achieve the filename alignment you are
> looking for.

Yeah, I think that is OK to me.

> Yes get_arch_regnum could make sense out of libdw and needn't just be
> a helper for it, but let's worry about that when there's a need.
> What's confusing at the moment is does libdw provide dwarf support,
> which I'd say is expected, or does dwarf provide libdw support?

You missed to cut the word, PERF_HAVE_DWARF_REGS means "perf have 
'dwarf-regs.c'". If dwarf-regs.c is not there, we can not enable
libdw support because it causes linker error.

So, if the file name simply changed to libdw-helper.c, I think we can
change it.

Thank you,

> 
> Thanks,
> Ian
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>

Powered by blists - more mailing lists