[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=V19pgzU8NSyWwHSEs85kU_Fbofcn8uJVj-TE2DNKfUHQ@mail.gmail.com>
Date: Tue, 18 Mar 2025 09:41:20 -0700
From: Doug Anderson <dianders@...omium.org>
To: Masahiro Yamada <masahiroy@...nel.org>
Cc: Frank Binns <frank.binns@...tec.com>, Matt Coster <matt.coster@...tec.com>,
linux-kernel@...r.kernel.org, Arnaldo Carvalho de Melo <acme@...hat.com>,
Borislav Petkov <bp@...e.de>, Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>,
bpf@...r.kernel.org, linux-kbuild@...r.kernel.org,
Stephen Boyd <swboyd@...omium.org>
Subject: Re: [PATCH] tools: fix annoying "mkdir -p ..." logs when building
tools in parallel
Hi,
On Mon, Feb 10, 2025 at 4:30 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
>
> When CONFIG_OBJTOOL=y or CONFIG_DEBUG_INFO_BTF=y, parallel builds
> show awkward "mkdir -p ..." logs.
>
> $ make -j16
> [ snip ]
> mkdir -p /home/masahiro/ref/linux/tools/objtool && make O=/home/masahiro/ref/linux subdir=tools/objtool --no-print-directory -C objtool
> mkdir -p /home/masahiro/ref/linux/tools/bpf/resolve_btfids && make O=/home/masahiro/ref/linux subdir=tools/bpf/resolve_btfids --no-print-directory -C bpf/resolve_btfids
>
> Defining MAKEFLAGS=<value> on the command line wipes out command line
> switches from the resultant MAKEFLAGS definition, even though the command
> line switches are active. [1]
>
> The first word of $(MAKEFLAGS) is a possibly empty group of characters
> representing single-letter options that take no argument. However, this
> breaks if MAKEFLAGS=<value> is given on the command line.
>
> The tools/ and tools/% targets set MAKEFLAGS=<value> on the command
> line, which breaks the following code in tools/scripts/Makefile.include:
>
> short-opts := $(firstword -$(MAKEFLAGS))
>
> If MAKEFLAGS really needs modification, it should be done through the
> environment variable, as follows:
>
> MAKEFLAGS=<value> $(MAKE) ...
>
> That said, I question whether modifying MAKEFLAGS is necessary here.
> The only flag we might want to exclude is --no-print-directory, as the
> tools build system changes the working directory. However, people might
> find the "Entering/Leaving directory" logs annoying.
>
> I simply removed the offending MAKEFLAGS=.
>
> [1]: https://savannah.gnu.org/bugs/?62469
>
> Fixes: a50e43332756 ("perf tools: Honor parallel jobs")
> Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> ---
>
> Makefile | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
I happened to sync up to mainline today and noticed that my build was
broken. I bisected it to this change and reverting this change fixes
my build on mainline.
In my case I'm building in a ChromeOS environment and using clang as
my compiler. I'm also cross-compiling an arm64 kernel on x86 host.
...but the pure mainline kernel should work there. Presumably the
environment is a bit different compared to the typical one, though?
The error comes up when doing a clean build and the first error messages are:
In file included from libbpf.c:36:
.../tools/include/uapi/linux/bpf_perf_event.h:14:21: error: field has
incomplete type
'bpf_user_pt_regs_t' (aka 'struct user_pt_regs')
14 | bpf_user_pt_regs_t regs;
| ^
.../tools/include/../../arch/arm64/include/uapi/asm/bpf_perf_event.h:7:16:
note: forward
declaration of 'struct user_pt_regs'
7 | typedef struct user_pt_regs bpf_user_pt_regs_t;
| ^
btf_dump.c:1860:10: error: cast to smaller integer type 'uintptr_t'
(aka 'unsigned int') from 'const void *'
[-Werror,-Wvoid-pointer-to-int-cast]
1860 | return ((uintptr_t)data) % alignment == 0;
| ^~~~~~~~~~~~~~~
btf_dump.c:2045:4: error: format specifies type 'ssize_t' (aka 'long')
but the argument has type 'ssize_t' (aka 'int')
[-Werror,-Wformat]
2044 | pr_warn("unexpected elem size %zd for array
type [%u]\n",
| ~~~
| %d
2045 | (ssize_t)elem_size, id);
| ^~~~~~~~~~~~~~~~~~
./libbpf_internal.h:171:52: note: expanded from macro 'pr_warn'
171 | #define pr_warn(fmt, ...) __pr(LIBBPF_WARN, fmt, ##__VA_ARGS__)
| ~~~ ^~~~~~~~~~~
I don't have time to dig right now, but I figured I'd at least post in
case the problem is obvious to someone else.
-Doug
Powered by blists - more mailing lists