Searched +hist:14 +hist:cdd3c4 (Results 1 - 3 of 3) sorted by relevance

/linux-master/scripts/kconfig/
H A Dlkc.hdiff adf7c5bd Mon Dec 16 21:14:23 MST 2019 Masahiro Yamada <masahiroy@kernel.org> kconfig: squash prop_alloc() into menu_add_prop()

prop_alloc() is only called from menu_add_prop(). Squash it.

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 18492685 Thu Mar 22 11:00:14 MDT 2018 Masahiro Yamada <yamada.masahiro@socionext.com> kconfig: use yylineno option instead of manual lineno increments

Tracking the line number by hand is error-prone since you need to
increment it in every \n matching pattern.

If '%option yylineno' is set, flex defines 'yylineno' to contain the
current line number and automatically updates it each time it reads a
\n character. This is much more convenient although the lexer does
not initializes yylineno, so you need to set it to 1 each time you
start reading a new file, and restore it you go back to the previous
file.

I tested this with DEBUG_PARSE, and confirmed the same dump message
was produced.

I removed the perf-report option. Otherwise, I see the following
message:
%option yylineno entails a performance penalty ONLY on rules that
can match newline characters

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff df60f4b9 Sun Oct 08 16:14:48 MDT 2017 Ulf Magnusson <ulfalizer@gmail.com> kconfig: Remove menu_end_entry()

menu_end_entry() is empty and completely unused as far as I can tell:

$ git log -G menu_end_entry --oneline
a02f057 [PATCH] kconfig: improve error handling in the parser
1da177e Linux-2.6.12-rc2

Last one is the initial Git commit, where menu_end_entry() is empty as
well. I couldn't find anything that redefined it on Google either.

It might be a debugging helper for setting a breakpoint after each
config, menuconfig, and comment is parsed. IMO it hurts more than it
helps in that case by making the parsing code look more complicated at a
glance than it really is, and I suspect it doesn't get used much.

Tested by running the Kconfiglib test suite, which indirectly verifies
that the .config files generated by the C implementation for each
defconfig file in the kernel stays the same.

Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
diff 3b9a19e0 Sun Apr 28 14:36:38 MDT 2013 Yann E. MORIN <yann.morin.1998@free.fr> kconfig: loop as long as we changed some symbols in randconfig

Because of choice-in-a-choice constructs, it can happen that not all
symbols are assigned a value during randconfig, leading in rare cases
to this situation:

---8<--- choice-in-choice.in
choice
bool "A/B/C"
config A
bool "A"

config B
bool "B"
if B
choice
bool "E/F"
config E
bool "E"
config F
bool "F"
endchoice
endif # B

config C
bool "C"
endchoice
---8<---

$ ./scripts/kconfig/conf --randconfig choice-in-choice.in
[--SNIP--]
$ ./scripts/kconfig/conf --silentoldconfig choice-in-choice.in </dev/null
[--SNIP--]
A/B/C
1. A (A)
> 2. B (B)
3. C (C)
choice[1-3]: 2
E/F
> 1. E (E) (NEW)
2. F (F) (NEW)
choice[1-2]: aborted!

Console input/output is redirected. Run 'make oldconfig' to update
configuration.

Fix this by looping in randconfig for as long as some symbol gets assigned
a value.

Note: this was spotted with the USB EHCI Debug Device Gadget (USB_G_DBGP),
which uses this choice-in-a-choice construct, and exhibits this problem.
The example above is just a stripped-down minimalist test-case.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
diff 5a6f8d2b Wed Jun 01 14:14:47 MDT 2011 Arnaud Lacombe <lacombar@gmail.com> kconfig: nuke LKC_DIRECT_LINK cruft

This interface is not (and has never been ?) used by any frontend, just get rid
of it.

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
diff 5a6f8d2b Wed Jun 01 14:14:47 MDT 2011 Arnaud Lacombe <lacombar@gmail.com> kconfig: nuke LKC_DIRECT_LINK cruft

This interface is not (and has never been ?) used by any frontend, just get rid
of it.

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
diff 2e7a0918 Sat Sep 04 14:03:30 MDT 2010 Arnaud Lacombe <lacombar@gmail.com> kconfig: constify file name

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Michal Marek <mmarek@suse.cz>
diff ffb5957b Sat Aug 14 21:57:43 MDT 2010 Arnaud Lacombe <lacombar@gmail.com> kconfig: allow build-time definition of the internal config prefix

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Michal Marek <mmarek@suse.cz>
diff d802b50f Sun Apr 01 14:29:38 MDT 2007 Sam Ravnborg <sam@neptun.ravnborg.org> kconfig/menuconfig: do not hardcode '.config'

Export and use the function conf_get_configname()
to retreive the default configuration filename.

Suggested by: Roman Zippel <zippel@linux-m68k.org>

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
diff 14cdd3c4 Thu Jun 08 23:12:51 MDT 2006 Roman Zippel <zippel@linux-m68k.org> kconfig: KCONFIG_OVERWRITECONFIG

If you set KCONFIG_OVERWRITECONFIG in environment, Kconfig will not break
symlinks when .config is a symlink to somewhere else.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
diff 14cdd3c4 Thu Jun 08 23:12:51 MDT 2006 Roman Zippel <zippel@linux-m68k.org> kconfig: KCONFIG_OVERWRITECONFIG

If you set KCONFIG_OVERWRITECONFIG in environment, Kconfig will not break
symlinks when .config is a symlink to somewhere else.

Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
H A Dconfdata.cdiff 8e2442a5 Fri Jul 12 00:07:09 MDT 2019 Masahiro Yamada <yamada.masahiro@socionext.com> kconfig: fix missing choice values in auto.conf

Since commit 00c864f8903d ("kconfig: allow all config targets to write
auto.conf if missing"), Kconfig creates include/config/auto.conf in the
defconfig stage when it is missing.

Joonas Kylmälä reported incorrect auto.conf generation under some
circumstances.

To reproduce it, apply the following diff:

| --- a/arch/arm/configs/imx_v6_v7_defconfig
| +++ b/arch/arm/configs/imx_v6_v7_defconfig
| @@ -345,14 +345,7 @@ CONFIG_USB_CONFIGFS_F_MIDI=y
| CONFIG_USB_CONFIGFS_F_HID=y
| CONFIG_USB_CONFIGFS_F_UVC=y
| CONFIG_USB_CONFIGFS_F_PRINTER=y
| -CONFIG_USB_ZERO=m
| -CONFIG_USB_AUDIO=m
| -CONFIG_USB_ETH=m
| -CONFIG_USB_G_NCM=m
| -CONFIG_USB_GADGETFS=m
| -CONFIG_USB_FUNCTIONFS=m
| -CONFIG_USB_MASS_STORAGE=m
| -CONFIG_USB_G_SERIAL=m
| +CONFIG_USB_FUNCTIONFS=y
| CONFIG_MMC=y
| CONFIG_MMC_SDHCI=y
| CONFIG_MMC_SDHCI_PLTFM=y

And then, run:

$ make ARCH=arm mrproper imx_v6_v7_defconfig

You will see CONFIG_USB_FUNCTIONFS=y is correctly contained in the
.config, but not in the auto.conf.

Please note drivers/usb/gadget/legacy/Kconfig is included from a choice
block in drivers/usb/gadget/Kconfig. So USB_FUNCTIONFS is a choice value.

This is probably a similar situation described in commit beaaddb62540
("kconfig: tests: test defconfig when two choices interact").

When sym_calc_choice() is called, the choice symbol forgets the
SYMBOL_DEF_USER unless all of its choice values are explicitly set by
the user.

The choice symbol is given just one chance to recall it because
set_all_choice_values() is called if SYMBOL_NEED_SET_CHOICE_VALUES
is set.

When sym_calc_choice() is called again, the choice symbol forgets it
forever, since SYMBOL_NEED_SET_CHOICE_VALUES is a one-time aid.
Hence, we cannot call sym_clear_all_valid() again and again.

It is crazy to repeat set and unset of internal flags. However, we
cannot simply get rid of "sym->flags &= flags | ~SYMBOL_DEF_USER;"
Doing so would re-introduce the problem solved by commit 5d09598d488f
("kconfig: fix new choices being skipped upon config update").

To work around the issue, conf_write_autoconf() stopped calling
sym_clear_all_valid().

conf_write() must be changed accordingly. Currently, it clears
SYMBOL_WRITE after the symbol is written into the .config file. This
is needed to prevent it from writing the same symbol multiple times in
case the symbol is declared in two or more locations. I added the new
flag SYMBOL_WRITTEN, to track the symbols that have been written.

Anyway, this is a cheesy workaround in order to suppress the issue
as far as defconfig is concerned.

Handling of choices is totally broken. sym_clear_all_valid() is called
every time a user touches a symbol from the GUI interface. To reproduce
it, just add a new symbol drivers/usb/gadget/legacy/Kconfig, then touch
around unrelated symbols from menuconfig. USB_FUNCTIONFS will disappear
from the .config file.

I added the Fixes tag since it is more fatal than before. But, this
has been broken since long long time before, and still it is.
We should take a closer look to fix this correctly somehow.

Fixes: 00c864f8903d ("kconfig: allow all config targets to write auto.conf if missing")
Cc: linux-stable <stable@vger.kernel.org> # 4.19+
Reported-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Joonas Kylmälä <joonas.kylmala@iki.fi>
diff a4663911 Wed Mar 16 14:27:27 MDT 2016 Paul Bolle <pebolle@tiscali.nl> kconfig: add unexpected data itself to warning

If the .config parser runs into unexpected data it emits warnings like:
.config:6911:warning: unexpected data

Add the unexpected data itself to this warning. That makes it easier to
discover what is actually going wrong:
.config:6911:warning: unexpected data: CONFOG_CHARGER_TPS65217=m

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Michal Marek <mmarek@suse.com>
diff 6b87b70c Thu Jan 14 11:13:49 MST 2016 Al Viro <viro@ZenIV.linux.org.uk> unbreak allmodconfig KCONFIG_ALLCONFIG=...

Prior to 3.13 make allmodconfig KCONFIG_ALLCONFIG=/dev/null used
to be equivalent to make allmodconfig; these days it hardwires MODULES to n.
In fact, any KCONFIG_ALLCONFIG that doesn't set MODULES explicitly is
treated as if it set it to n.

Regression had been introduced by commit cfa98f ("kconfig: do not
override symbols already set"); what happens is that conf_read_simple()
does sym_calc_value(modules_sym) on exit, which leaves SYMBOL_VALID set and
has conf_set_all_new_symbols() skip modules_sym.

It's pretty easy to fix - simply move that call of sym_calc_value()
into the callers, except for the ones in KCONFIG_ALLCONFIG handling.
Objections?

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Fixes: cfa98f2e0ae9 ("kconfig: do not override symbols already set")
Signed-off-by: Michal Marek <mmarek@suse.com>
diff 3b9a19e0 Sun Apr 28 14:36:38 MDT 2013 Yann E. MORIN <yann.morin.1998@free.fr> kconfig: loop as long as we changed some symbols in randconfig

Because of choice-in-a-choice constructs, it can happen that not all
symbols are assigned a value during randconfig, leading in rare cases
to this situation:

---8<--- choice-in-choice.in
choice
bool "A/B/C"
config A
bool "A"

config B
bool "B"
if B
choice
bool "E/F"
config E
bool "E"
config F
bool "F"
endchoice
endif # B

config C
bool "C"
endchoice
---8<---

$ ./scripts/kconfig/conf --randconfig choice-in-choice.in
[--SNIP--]
$ ./scripts/kconfig/conf --silentoldconfig choice-in-choice.in </dev/null
[--SNIP--]
A/B/C
1. A (A)
> 2. B (B)
3. C (C)
choice[1-3]: 2
E/F
> 1. E (E) (NEW)
2. F (F) (NEW)
choice[1-2]: aborted!

Console input/output is redirected. Run 'make oldconfig' to update
configuration.

Fix this by looping in randconfig for as long as some symbol gets assigned
a value.

Note: this was spotted with the USB EHCI Debug Device Gadget (USB_G_DBGP),
which uses this choice-in-a-choice construct, and exhibits this problem.
The example above is just a stripped-down minimalist test-case.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
diff 23a5dfda Fri Apr 26 14:41:32 MDT 2013 Yann E. MORIN <yann.morin.1998@free.fr> Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"

This reverts commit 422c809f03f043d0950d8362214818e956a9daee.
It causes more harm than it solves issues.

Reported-by: Sedat Dilek <sedat.dilek@gmail.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Sedat Dilek <sedat.dilek@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Michal Marek <mmarek@suse.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Greg KH <greg@kroah.com>
diff cfa98f2e Wed Apr 24 14:00:04 MDT 2013 Yann E. MORIN <yann.morin.1998@free.fr> kconfig: do not override symbols already set

For randconfig, if a list of required symbols is specified with
KCONFIG_ALLCONFIG, such symbols do not "have a value" as per
sym_has_value(), but have the "valid" flag set.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
diff 61fa0e17 Wed Apr 24 10:14:27 MDT 2013 Yann E. MORIN <yann.morin.1998@free.fr> kconfig: fix randconfig tristate detection

Because the modules' symbole (CONFIG_MODULES) may not yet be set when
we check a symbol's tristate capabilty, we'll always find that tristate
symbols are booleans, even if we randomly decided that to enable modules:
sym_get_type(sym) always return boolean for tristates when modules_sym
has not been previously set to 'y' *and* its value calculated *and* its
visibility calculated, both of which only occur after we randomly assign
values to symbols.

Fix that by looking at the raw type of symbols. Tristate set to 'm' will
be promoted to 'y' when their values will be later calculated.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
diff eb4cf5a6 Thu Jul 14 13:31:07 MDT 2011 Arnaud Lacombe <lacombar@gmail.com> kconfig: fix missing "0x" prefix from S_HEX symbol in autoconf.h

The specialized printer for headers (espectially autoconf.h) is missing
fixup code for S_HEX symbol's "0x" prefix. As long as kconfig does not
warn for such missing prefix, this code is needed. Fix this.

In the same time, fix some nits in `header_print_symbol()'.

Cc: Randy Dunlap <rdunlap@xenotime.net>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>

Broken-by: Arnaud Lacombe <lacombar@gmail.com>
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Reported-by: Mauro Carvalho Chehab <mchehab@infradead.org>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
diff 5a6f8d2b Wed Jun 01 14:14:47 MDT 2011 Arnaud Lacombe <lacombar@gmail.com> kconfig: nuke LKC_DIRECT_LINK cruft

This interface is not (and has never been ?) used by any frontend, just get rid
of it.

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
diff 5a6f8d2b Wed Jun 01 14:14:47 MDT 2011 Arnaud Lacombe <lacombar@gmail.com> kconfig: nuke LKC_DIRECT_LINK cruft

This interface is not (and has never been ?) used by any frontend, just get rid
of it.

Signed-off-by: Arnaud Lacombe <lacombar@gmail.com>
/linux-master/
H A DMakefilediff 6272cc38 Mon Aug 16 14:20:56 MDT 2021 Nathan Chancellor <nathan@kernel.org> kbuild: Shuffle blank line to improve comment meaning

-Wunused-but-set-variable and -Wunused-const-variable are both disabled
for the same reason but there is a blank line between them and no blank
line between -Wno-unused-const-variable and the block.

Shuffle the new line so that it is clear that the comment applied to
both flags and the next block is separate from them.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 5c6ae0ef Mon Aug 16 14:20:55 MDT 2021 Nathan Chancellor <nathan@kernel.org> kbuild: Add a comment above -Wno-gnu

Whenever a warning is disabled, it is helpful for future travelers to
understand why the warning is disabled and why it is acceptable to do
so. Add a comment for -Wno-gnu so that people understand why it is
disabled.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff a312b60d Mon Aug 16 14:20:54 MDT 2021 Nathan Chancellor <nathan@kernel.org> kbuild: Remove -Wno-format-invalid-specifier from clang block

Turning on -Wformat does not reveal any instances of this warning across
several different builds so remove this line to keep the number of
disabled warnings as slim as possible.

This has been disabled since commit 61163efae020 ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang"), which does not
explain exactly why it was turned off but since it was so long ago in
terms of both the kernel and LLVM so it is possible that some bug got
fixed along the way.

Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 7d73c3e9 Mon Aug 16 14:25:01 MDT 2021 Nick Desaulniers <ndesaulniers@google.com> Makefile: remove stale cc-option checks

cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.

The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack

The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds

The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH

-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.

--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.

-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.

Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff 36a21d51 Sun Aug 08 14:49:31 MDT 2021 Linus Torvalds <torvalds@linux-foundation.org> Linux 5.14-rc5
diff 14ccc638 Wed Jul 28 18:12:54 MDT 2021 Masahiro Yamada <masahiroy@kernel.org> kbuild: cancel sub_make_done for the install target to fix DKMS

Since commit bcf637f54f6d ("kbuild: parse C= and M= before changing the
working directory"), external module builds invoked by DKMS fail because
M= option is not parsed.

I wanted to add 'unset sub_make_done' in install.sh but similar scripts,
arch/*/boot/install.sh, are duplicated, so I set sub_make_done empty in
the top Makefile.

Fixes: bcf637f54f6d ("kbuild: parse C= and M= before changing the working directory")
Reported-by: John S Gruber <johnsgruber@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: John S Gruber <johnsgruber@gmail.com>
diff ff117646 Sun Jul 25 16:35:14 MDT 2021 Linus Torvalds <torvalds@linux-foundation.org> Linux 5.14-rc3
diff f634ca65 Thu Apr 22 14:19:14 MDT 2021 Nathan Chancellor <nathan@kernel.org> kbuild: Add $(KBUILD_HOSTLDFLAGS) to 'has_libelf' test

Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which
in turn includes $(HOSTLDFLAGS), which allows users to pass in their own
flags when linking. However, the 'has_libelf' test does not, meaning
that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=...,
it is not respected and the build might error.

For example, if a user building with clang wants to use all of the LLVM
tools without any GNU tools, they might remove all of the GNU tools from
their system or PATH then build with

$ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1

which says use all of the LLVM tools, the integrated assembler, and
ld.lld for linking host executables. Without this change, the build will
error because $(HOSTCC) uses its default linker, rather than the one
requested via -fuse-ld=..., which is GNU ld in clang's case in a default
configuration.

error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
install libelf-dev, libelf-devel or elfutils-libelf-devel
make[1]: *** [Makefile:1260: prepare-objtool] Error 1

Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker
choice is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/479
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff f634ca65 Thu Apr 22 14:19:14 MDT 2021 Nathan Chancellor <nathan@kernel.org> kbuild: Add $(KBUILD_HOSTLDFLAGS) to 'has_libelf' test

Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which
in turn includes $(HOSTLDFLAGS), which allows users to pass in their own
flags when linking. However, the 'has_libelf' test does not, meaning
that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=...,
it is not respected and the build might error.

For example, if a user building with clang wants to use all of the LLVM
tools without any GNU tools, they might remove all of the GNU tools from
their system or PATH then build with

$ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1

which says use all of the LLVM tools, the integrated assembler, and
ld.lld for linking host executables. Without this change, the build will
error because $(HOSTCC) uses its default linker, rather than the one
requested via -fuse-ld=..., which is GNU ld in clang's case in a default
configuration.

error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
install libelf-dev, libelf-devel or elfutils-libelf-devel
make[1]: *** [Makefile:1260: prepare-objtool] Error 1

Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker
choice is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/479
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
diff c91d4e47 Tue Mar 09 13:59:14 MST 2021 Nathan Chancellor <nathan@kernel.org> Makefile: Remove '--gcc-toolchain' flag

This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa595b ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9db80 ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6bb9c ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.

This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.

Link: https://reviews.llvm.org/D97902
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Completed in 302 milliseconds