linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@kernel.org>
To: Ian Rogers <irogers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Tom Rix <trix@redhat.com>, Masahiro Yamada <masahiroy@kernel.org>,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
	Stephane Eranian <eranian@google.com>,
	Andrii Nakryiko <andrii@kernel.org>, Jiri Olsa <jolsa@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>
Subject: Re: [PATCH v3 3/3] objtool: Alter how HOSTCC is forced
Date: Wed, 25 Jan 2023 17:49:42 -0800	[thread overview]
Message-ID: <20230126014942.kuynrl56b2u4npj6@treble> (raw)
In-Reply-To: <20230105090155.357604-4-irogers@google.com>

On Thu, Jan 05, 2023 at 01:01:55AM -0800, Ian Rogers wrote:
> HOSTCC is always wanted when building objtool. Setting CC to HOSTCC
> happens after tools/scripts/Makefile.include is included, meaning
> flags are set assuming say CC is gcc, but then it can be later set to
> HOSTCC which may be clang. tools/scripts/Makefile.include is needed
> for host set up and common macros in objtool's Makefile. Rather than
> override CC to HOSTCC, just pass CC as HOSTCC to Makefile.build, the
> libsubcmd builds and the linkage step. This means the Makefiles don't
> see things like CC changing and tool flag determination, and similar,
> work properly.

I'm having trouble parsing this last sentence, can you rephrase or
restructure it?

> To avoid mixing CFLAGS from different compilers just
> the objtool CFLAGS are determined with the exception of
> EXTRA_WARNINGS.

I'm not really sure what this one means either.

> HOSTCFLAGS is added to these so that command line
> flags can add to the CFLAGS.

Overall this patch description is a big wall of dense text which I found
hard to decipher.  Please split it up into paragraphs and make it more
legible and logical.

For example, un-jumble the ordering, with the background first, then the
problem(s), then the fix(es).  (At least three paragraphs)

If possible, the subject should describe the end result for the user,
something like

  objtool: Fix HOSTCFLAGS cmdline support

... unless I'm misunderstanding the point of the patch.

HOSTCFLAGS from the cmdline *used* to work, a git bisect shows it
stopped working with

  96f14fe738b6 ("kbuild: Rename HOSTCFLAGS to KBUILD_HOSTCFLAGS")

... so please add a "Fixes" tag for that commit.

> +MAKE = make -S

Why?

>  LIBSUBCMD_DIR = $(srctree)/tools/lib/subcmd/
>  ifneq ($(OUTPUT),)
>    LIBSUBCMD_OUTPUT = $(abspath $(OUTPUT))/libsubcmd
> @@ -37,12 +33,19 @@ INCLUDES := -I$(srctree)/tools/include \
>  	    -I$(srctree)/tools/objtool/arch/$(SRCARCH)/include \
>  	    -I$(LIBSUBCMD_OUTPUT)/include
>  WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed -Wno-nested-externs
> -CFLAGS   := -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES) $(LIBELF_FLAGS)
> -LDFLAGS  += $(LIBELF_LIBS) $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
> +OBJTOOL_CFLAGS := -Werror $(WARNINGS) -g $(INCLUDES) $(LIBELF_FLAGS) $(HOSTCFLAGS)

I *think* I understand the reason for the switch from KBUILD_HOSTCFLAGS
to HOSTCFLAGS -- because KBUILD_HOSTCFLAGS is defined in the top-level
kernel Makefile which isn't included here so it's undefined? -- but
regardless that should be called out more explicitly as a problem being
fixed in the commit log.

This issue really has me scratching my head, as I could have sworn
objtool was being built with -O2.

> +OBJTOOL_LDFLAGS := $(LIBELF_LIBS) $(LIBSUBCMD)

Is there a reason to not include $(HOSTLDFLAGS) here?

>  # Allow old libelf to be used:
>  elfshdr := $(shell echo '$(pound)include <libelf.h>' | $(CC) $(CFLAGS) -x c -E - | grep elf_getshdr)
> -CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
> +OBJTOOL_CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
> +
> +# Always want host compilation.
> +HOST_OVERRIDES := CC="$(HOSTCC)" EXTRA_CFLAGS="$(OBJTOOL_CFLAGS)" \
> +		  LD="$(HOSTLD)" AR="$(HOSTAR)"
> +BUILD_HOST_OVERRIDES := CC="$(HOSTCC)" CFLAGS="$(OBJTOOL_CFLAGS)" \
> +			LD="$(HOSTLD)" LDFLAGS="$(OBJTOOL_LDFLAGS)" \
> +			AR="$(HOSTAR)"

Maybe it depends on your perspective, but I'm thinking that some of
these aren't really overrides, but rather normal expected flags.  And
the distinction between these two variables is muddy: it's not only
Build vs non-Build, but also objtool vs libsubcmd.

How about just

  HOST_OVERRIDES := CC="$(HOSTCC) "LD="$(HOSTLD)" AR="$(HOSTAR)"

And then specifying the {EXTRA_}CFLAGS and LDFLAGS below where needed.

>  AWK = awk
>  MKDIR = mkdir
> @@ -65,10 +68,11 @@ include $(srctree)/tools/build/Makefile.include
>  
>  $(OBJTOOL_IN): fixdep FORCE
>  	$(Q)$(CONFIG_SHELL) ./sync-check.sh
> -	$(Q)$(MAKE) $(build)=objtool
> +	$(Q)$(MAKE) $(build)=objtool $(BUILD_HOST_OVERRIDES)
> +
>  
>  $(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN)
> -	$(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@
> +	$(QUIET_LINK)$(HOSTCC) $(OBJTOOL_IN) $(KBUILD_HOSTLDFLAGS) $(OBJTOOL_LDFLAGS) -o $@

Does KBUILD_HOSTLDFLAGS even work here?

-- 
Josh

  parent reply	other threads:[~2023-01-26  1:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-05  9:01 [PATCH v3 0/3] objtool build improvements Ian Rogers
2023-01-05  9:01 ` [PATCH v3 1/3] objtool: Install libsubcmd in build Ian Rogers
2023-01-12 20:25   ` Nicolas Schier
2023-01-12 20:54     ` Ian Rogers
2023-01-26  1:46   ` Josh Poimboeuf
2023-01-26 17:50     ` Ian Rogers
2023-01-05  9:01 ` [PATCH v3 2/3] objtool: Properly support make V=1 Ian Rogers
2023-01-12 20:31   ` Nicolas Schier
2023-01-05  9:01 ` [PATCH v3 3/3] objtool: Alter how HOSTCC is forced Ian Rogers
2023-01-09 23:05   ` Nick Desaulniers
2023-01-12 20:40   ` Nicolas Schier
2023-01-26  1:49   ` Josh Poimboeuf [this message]
2023-01-26 18:30     ` Ian Rogers
2023-01-12 17:41 ` [PATCH v3 0/3] objtool build improvements Ian Rogers
2023-01-19 16:12   ` Ian Rogers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230126014942.kuynrl56b2u4npj6@treble \
    --to=jpoimboe@kernel.org \
    --cc=acme@kernel.org \
    --cc=andrii@kernel.org \
    --cc=eranian@google.com \
    --cc=irogers@google.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    --cc=nicolas@fjasle.eu \
    --cc=peterz@infradead.org \
    --cc=trix@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).