[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZrDwOmWR97lNOlnH@x1>
Date: Mon, 5 Aug 2024 12:31:06 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Jiri Olsa <olsajiri@...il.com>, Brian Norris <briannorris@...omium.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Namhyung Kim <namhyung@...nel.org>, Ian Rogers <irogers@...gle.com>,
Thomas Richter <tmricht@...ux.ibm.com>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
Masahiro Yamada <masahiroy@...nel.org>, bpf@...r.kernel.org,
linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v4 2/3] tools build: Avoid circular .fixdep-in.o.cmd
issues
On Fri, Jul 19, 2024 at 11:32:08AM -0700, Andrii Nakryiko wrote:
> On Tue, Jul 16, 2024 at 12:55 AM Jiri Olsa <olsajiri@...il.com> wrote:
> >
> > On Mon, Jul 15, 2024 at 01:32:43PM -0700, Brian Norris wrote:
> > > The 'fixdep' tool is used to post-process dependency files for various
> > > reasons, and it runs after every object file generation command. This
> > > even includes 'fixdep' itself.
> > >
> > > In Kbuild, this isn't actually a problem, because it uses a single
> > > command to generate fixdep (a compile-and-link command on fixdep.c), and
> > > afterward runs the fixdep command on the accompanying .fixdep.cmd file.
> > >
> > > In tools/ builds (which notably is maintained separately from Kbuild),
> > > fixdep is generated in several phases:
> > >
> > > 1. fixdep.c -> fixdep-in.o
> > > 2. fixdep-in.o -> fixdep
> > >
> > > Thus, fixdep is not available in the post-processing for step 1, and
> > > instead, we generate .cmd files that look like:
> > >
> > > ## from tools/objtool/libsubcmd/.fixdep.o.cmd
> > > # cannot find fixdep (/path/to/linux/tools/objtool/libsubcmd//fixdep)
> > > [...]
> > >
> > > These invalid .cmd files are benign in some respects, but cause problems
> > > in others (such as the linked reports).
> > >
> > > Because the tools/ build system is rather complicated in its own right
> > > (and pointedly different than Kbuild), I choose to simply open-code the
> > > rule for building fixdep, and avoid the recursive-make indirection that
> > > produces the problem in the first place.
> > >
> > > Link: https://lore.kernel.org/all/Zk-C5Eg84yt6_nml@google.com/
> > > Signed-off-by: Brian Norris <briannorris@...omium.org>
> > > ---
> > >
> > > (no changes since v3)
> > >
> > > Changes in v3:
> > > - Drop unnecessary tools/build/Build
> >
> > Acked-by: Jiri Olsa <jolsa@...nel.org>
> >
> > so usually Arnaldo takes changes for tools/build, Arnaldo, could you please take a look?
> > but still there'are the tools/lib/bpf bits..
>
> I think it should be fine for libbpf bits to go through Arnaldo's tree
> and get back to bpf-next eventually. Unlikely that we'll have any
> conflict in libbpf's Makefile specifically, we rarely change it.
I got this series now in perf-tools-next,
Thanks,
- Arnaldo
Powered by blists - more mailing lists