linux.git/Documentation/kbuild, branch v5.4.63

kbuild: support LLVM=1 to switch the default tools to Clang/LLVM

2020-08-26T08:40:47+00:00

commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream.

As Documentation/kbuild/llvm.rst implies, building the kernel with a
full set of LLVM tools gets very verbose and unwieldy.

Provide a single switch LLVM=1 to use Clang and LLVM tools instead
of GCC and Binutils. You can pass it from the command line or as an
environment variable.

Please note LLVM=1 does not turn on the integrated assembler. You need
to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the
integrated assembler, I think we can make it default.

We discussed what we need, and we agreed to go with a simple boolean
flag that switches both target and host tools:

  https://lkml.org/lkml/2020/3/28/494
  https://lkml.org/lkml/2020/4/3/43

Some items discussed, but not adopted:

- LLVM_DIR

  When multiple versions of LLVM are installed, I just thought supporting
  LLVM_DIR=/path/to/my/llvm/bin/ might be useful.

  CC      = $(LLVM_DIR)clang
  LD      = $(LLVM_DIR)ld.lld
    ...

  However, we can handle this by modifying PATH. So, we decided to not do
  this.

- LLVM_SUFFIX

  Some distributions (e.g. Debian) package specific versions of LLVM with
  naming conventions that use the version as a suffix.

  CC      = clang$(LLVM_SUFFIX)
  LD      = ld.lld(LLVM_SUFFIX)
    ...

  will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc.,
  but the suffixed versions in /usr/bin/ are symlinks to binaries in
  /usr/lib/llvm-#/bin/, so this can also be handled by PATH.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor  # build
Tested-by: Nick Desaulniers 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

kbuild: replace AS=clang with LLVM_IAS=1

2020-08-26T08:40:47+00:00

commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream.

The 'AS' variable is unused for building the kernel. Only the remaining
usage is to turn on the integrated assembler. A boolean flag is a better
fit for this purpose.

AS=clang was added for experts. So, I replaced it with LLVM_IAS=1,
breaking the backward compatibility.

Suggested-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

Documentation/llvm: fix the name of llvm-size

2020-08-26T08:40:46+00:00

commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream.

The tool is called llvm-size, not llvm-objsize.

Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM")
Signed-off-by: Fangrui Song 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Nathan Chancellor 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Greg Kroah-Hartman

Documentation/llvm: add documentation on building w/ Clang/LLVM

2020-08-26T08:40:46+00:00

commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream.

added to kbuild documentation. Provides more official info on building
kernels with Clang and LLVM than our wiki.

Suggested-by: Kees Cook 
Reviewed-by: Kees Cook 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Sedat Dilek 
Signed-off-by: Nick Desaulniers 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Greg Kroah-Hartman

modpost: move the namespace field in Module.symvers last

2020-03-25T07:25:55+00:00

commit 5190044c2965514a973184ca68ef5fad57a24670 upstream.

In order to preserve backwards compatability with kmod tools, we have to
move the namespace field in Module.symvers last, as the depmod -e -E
option looks at the first three fields in Module.symvers to check symbol
versions (and it's expected they stay in the original order of crc,
symbol, module).

In addition, update an ancient comment above read_dump() in modpost that
suggested that the export type field in Module.symvers was optional. I
suspect that there were historical reasons behind that comment that are
no longer accurate. We have been unconditionally printing the export
type since 2.6.18 (commit bd5cbcedf44), which is over a decade ago now.

Fix up read_dump() to treat each field as non-optional. I suspect the
original read_dump() code treated the export field as optional in order
to support pre <= 2.6.18 Module.symvers (which did not have the export
type field). Note that although symbol namespaces are optional, the
field will not be omitted from Module.symvers if a symbol does not have
a namespace. In this case, the field will simply be empty and the next
delimiter or end of line will follow.

Cc: stable@vger.kernel.org
Fixes: cb9b55d21fe0 ("modpost: add support for symbol namespaces")
Tested-by: Matthias Maennich 
Reviewed-by: Matthias Maennich 
Reviewed-by: Lucas De Marchi 
Signed-off-by: Jessica Yu 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Greg Kroah-Hartman

kbuild: remove header compile test

2020-03-05T15:43:47+00:00

commit fcbb8461fd2376ba3782b5b8bd440c929b8e4980 upstream.

There are both positive and negative options about this feature.
At first, I thought it was a good idea, but actually Linus stated a
negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
is ugly and annoying.

The baseline I'd like to keep is the compile-test of uapi headers.
(Otherwise, kernel developers have no way to ensure the correctness
of the exported headers.)

I will maintain a small build rule in usr/include/Makefile.
Remove the other header test functionality.

Signed-off-by: Masahiro Yamada 
[ added to 5.4.y due to start of build warnings from backported patches
  because of this feature - gregkh]
Signed-off-by: Greg Kroah-Hartman

Merge tag 'modules-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux

2019-10-11T17:19:24+00:00

Pull module fixes from Jessica Yu:
 "Code cleanups and kbuild/namespace related fixups from Masahiro.

  Most importantly, it fixes a namespace-related modpost issue for
  external module builds

   - Fix broken external module builds due to a modpost bug in
     read_dump(), where the namespace was not being strdup'd and
     sym->namespace would be set to bogus data.

   - Various namespace-related kbuild fixes and cleanups thanks to
     Masahiro Yamada"

* tag 'modules-for-v5.4-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/jeyu/linux:
  doc: move namespaces.rst from kbuild/ to core-api/
  nsdeps: make generated patches independent of locale
  nsdeps: fix hashbang of scripts/nsdeps
  kbuild: fix build error of 'make nsdeps' in clean tree
  module: rename __kstrtab_ns_* to __kstrtabns_* to avoid symbol conflict
  modpost: fix broken sym->namespace for external module builds
  module: swap the order of symbol.namespace
  scripts: add_namespace: Fix coccicheck failed

doc: move namespaces.rst from kbuild/ to core-api/

2019-10-08T15:40:01+00:00

We discussed a better location for this file, and agreed that
core-api/ is a good fit. Rename it to symbol-namespaces.rst
for disambiguation, and also add it to index.rst and MAINTAINERS.

Signed-off-by: Masahiro Yamada 
Acked-by: Matthias Maennich 
Signed-off-by: Jessica Yu

kheaders: make headers archive reproducible

2019-10-05T06:29:49+00:00

In commit 43d8ce9d65a5 ("Provide in-kernel headers to make
extending kernel easier") a new mechanism was introduced, for kernels
>=5.2, which embeds the kernel headers in the kernel image or a module
and exposes them in procfs for use by userland tools.

The archive containing the header files has nondeterminism caused by
header files metadata. This patch normalizes the metadata and utilizes
KBUILD_BUILD_TIMESTAMP if provided and otherwise falls back to the
default behaviour.

In commit f7b101d33046 ("kheaders: Move from proc to sysfs") it was
modified to use sysfs and the script for generation of the archive was
renamed to what is being patched.

Signed-off-by: Dmitry Goldin 
Reviewed-by: Greg Kroah-Hartman 
Reviewed-by: Joel Fernandes (Google) 
Signed-off-by: Masahiro Yamada

kbuild: two minor updates for Documentation/kbuild/modules.rst

2019-10-05T06:29:49+00:00

Capitalize the first word in the sentence.

Use obj-m instead of obj-y. obj-y still works, but we have no built-in
objects in external module builds. So, obj-m is better IMHO.

Signed-off-by: Masahiro Yamada