Avoid "gcc" since it is not the only compiler supported by Kbuild.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Building external modules is typically done using this command:

  $ make -C <KERNEL_DIR> M=<EXTMOD_DIR>

Here, <KERNEL_DIR> refers to the output directory where the kernel was
built, not the kernel source directory.

When the kernel is built in the source tree, there is no ambiguity, as
the output directory and the source directory are the same.

If the kernel was built in a separate build directory, <KERNEL_DIR>
should be the kernel output directory. Otherwise, Kbuild cannot locate
necessary build artifacts. This has been the method for building
external modules against a pre-built kernel in a separate directory
for over 20 years. [1]

If you pass the kernel source directory to the -C option, you must also
specify the kernel build directory using the O= option. This approach
works as well, though it results in a slightly longer command:

  $ make -C <KERNEL_SOURCE_DIR> O=<KERNEL_BUILD_DIR> M=<EXTMOD_DIR>

Some people mistakenly believe that O= should specify a build directory
for external modules when used together with M=. This commit adds more
clarification to Documentation/kbuild/kbuild.rst.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=e321b2ec2eb2993b3d0116e5163c78ad923e3c54Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

The use of shipped files is discouraged in the upstream kernel these
days. [1]

Downstream Makefiles have the freedom to use shipped files or other
options to handle binaries, but this should not be advertised in the
upstream document.

[1]: https://lore.kernel.org/all/CAHk-=wgSEi_ZrHdqr=20xv+d6dr5G895CbOAi8ok+7-CQUN=fQ@mail.gmail.com/Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

Do similar to commit 1a4c1c9d ("docs/kbuild/makefiles: drop section
numbering, use references").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Do similar to commit 5e8f0ba3 ("docs/kbuild/makefiles: throw out the
local table of contents").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Kbuild used to manipulate header search paths, enforcing the odd
limitation of "no space after -I".

Commit cdd750bf ("kbuild: remove 'addtree' and 'flags' magic for
header search paths") stopped doing that. This limitation no longer
exists. Instead, you need to accurately specify the header search path.
(In this case, $(src)/include)
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

This description was added 20 years ago [1]. It does not convey any
useful information except for a feeling of nostalgia.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=65e433436b5794ae056d22ddba60fe9194bba007Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

The phrase "In newer versions of the kernel" was added 14 years ago, by
commit efdf02cf ("Documentation/kbuild: major edit of modules.txt
sections 1-4"). This feature is no longer new, so remove it and update
the paragraph.

Example 3 was written 20 years ago [1]. There is no need to note about
backward compatibility with such an old build system. Remove Example 3
entirely.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=65e433436b5794ae056d22ddba60fe9194bba007Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <n.schier@avm.de>

If RUST_LIB_SRC is defined in the top-level Makefile (via an environment
variable or command line), it is already exported.

The only situation where it is defined but not exported is when the
top-level Makefile is wrapped by another Makefile (e.g., GNUmakefile).
I cannot think of any other use cases.

I know some people use this tip to define custom variables. However,
even in that case, you can export it directly in the wrapper Makefile.

Example GNUmakefile:

    export RUST_LIB_SRC = /path/to/your/sysroot/lib/rustlib/src/rust/library
    include Makefile
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>

The append operation was introduced in
commit b1a1a1a0 ("kbuild: lto: postpone objtool")
when the command was created from two parts.
In commit 850ded46 ("kbuild: Fix TRIM_UNUSED_KSYMS with LTO_CLANG")
however the first part was removed again, making the append operation
unnecessary.

To keep this command definition aligned with all other command
definitions, remove the append again.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Cache expression values to avoid recalculating them repeatedly.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, every expression in Kconfig files produces a new abstract
syntax tree (AST), even if it is identical to a previously encountered
one.

Consider the following code:

    config FOO
           bool "FOO"
           depends on (A || B) && C

    config BAR
           bool "BAR"
           depends on (A || B) && C

    config BAZ
           bool "BAZ"
           depends on A || B

The "depends on" lines are similar, but currently a separate AST is
allocated for each one.

The current data structure looks like this:

  FOO->dep ==> AND        BAR->dep ==> AND        BAZ->dep ==> OR
              /   \                   /   \                   /  \
            OR     C                OR     C                 A    B
           /  \                    /  \
          A    B                  A    B

This is redundant; FOO->dep and BAR->dep have identical ASTs but
different memory instances.

We can optimize this; FOO->dep and BAR->dep can share the same AST, and
BAZ->dep can reference its sub tree.

The optimized data structure looks like this:

  FOO->dep, BAR->dep ==> AND
                        /   \
         BAZ->dep ==> OR     C
                     /  \
                    A    B

This commit introduces a hash table to keep track of allocated
expressions. If an identical expression is found, it is reused.

This does not necessarily result in memory savings, as menu_finalize()
transforms expressions without freeing up stale ones. This will be
addressed later.

One optimization that can be easily implemented is caching the
expression's value. Once FOO's dependency, (A || B) && C, is calculated,
it can be cached, eliminating the need to recalculate it for BAR.

This commit also reverts commit e983b7b1 ("kconfig/menu.c: fix
multiple references to expressions in menu_add_prop()").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Currently, expr_eliminate_dups() passes two identical pointers down to
expr_eliminate_dups1(), which later skips processing identical leaves.

This approach is somewhat tricky and, more importantly, it will not work
with the refactoring made in the next commit.

This commit slightly changes the recursion logic; it deduplicates both
the left and right arms, and then passes them to expr_eliminate_dups1().
expr_eliminate_dups() should produce the same result.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Provide explanations for complex transformations.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This clarifies the behavior of these functions.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This function was originally added by commit 8af27e1d ("fixdep: use
hash table instead of a single array").

Move it to scripts/include/ so that other host programs can use it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Change the 'overflow' variable to bool. Also, remove unnecessary
parentheses.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

After commit 64e16609 ("kallsyms: get rid of code for absolute,
kallsyms"), there is only one call site for output_address(). Squash it.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When CONFIG_BUILTIN_MODULE_RANGES is enabled, the modules.builtin.ranges
file should be installed in the module install location.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

The modules.builtin.ranges offset range data for builtin modules is
generated at compile time based on the list of built-in modules and
the vmlinux.map and vmlinux.o.map linker maps.  This data can be used
to determine whether a symbol at a particular address belongs to
module code that was configured to be compiled into the kernel proper
as a built-in module (rather than as a standalone module).

This patch adds a script that uses the generated modules.builtin.ranges
data to annotate the symbols in the System.map with module names if
their address falls within a range that belongs to one or more built-in
modules.

It then processes the vmlinux.map (and if needed, vmlinux.o.map) to
verify the annotation:

  - For each top-level section:
     - For each object in the section:
        - Determine whether the object is part of a built-in module
          (using modules.builtin and the .*.cmd file used to compile
           the object as suggested in [0])
        - For each symbol in that object, verify that the built-in
          module association (or lack thereof) matches the annotation
          given to the symbol.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.

The offset range data for builtin modules is generated using:
 - modules.builtin: associates object files with module names
 - vmlinux.map: provides load order of sections and offset of first member
    per section
 - vmlinux.o.map: provides offset of object file content per section
 - .*.cmd: build cmd file with KBUILD_MODFILE

The generated data will look like:

.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore

For each ELF section, it lists the offset of the first symbol.  This can
be used to determine the base address of the section at runtime.

Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules.  Multiple ranges
can apply to a single module, and ranges can be shared between modules.

The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.

How it works:

 1. The modules.builtin file is parsed to obtain a list of built-in
    module names and their associated object names (the .ko file that
    the module would be in if it were a loadable module, hereafter
    referred to as <kmodfile>).  This object name can be used to
    identify objects in the kernel compile because any C or assembler
    code that ends up into a built-in module will have the option
    -DKBUILD_MODFILE=<kmodfile> present in its build command, and those
    can be found in the .<obj>.cmd file in the kernel build tree.

    If an object is part of multiple modules, they will all be listed
    in the KBUILD_MODFILE option argument.

    This allows us to conclusively determine whether an object in the
    kernel build belong to any modules, and which.

 2. The vmlinux.map is parsed next to determine the base address of each
    top level section so that all addresses into the section can be
    turned into offsets.  This makes it possible to handle sections
    getting loaded at different addresses at system boot.

    We also determine an 'anchor' symbol at the beginning of each
    section to make it possible to calculate the true base address of
    a section at runtime (i.e. symbol address - symbol offset).

    We collect start addresses of sections that are included in the top
    level section.  This is used when vmlinux is linked using vmlinux.o,
    because in that case, we need to look at the vmlinux.o linker map to
    know what object a symbol is found in.

    And finally, we process each symbol that is listed in vmlinux.map
    (or vmlinux.o.map) based on the following structure:

    vmlinux linked from vmlinux.a:

      vmlinux.map:
        <top level section>
          <included section>  -- might be same as top level section)
            <object>          -- built-in association known
              <symbol>        -- belongs to module(s) object belongs to
              ...

    vmlinux linked from vmlinux.o:

      vmlinux.map:
        <top level section>
          <included section>  -- might be same as top level section)
            vmlinux.o         -- need to use vmlinux.o.map
              <symbol>        -- ignored
              ...

      vmlinux.o.map:
        <section>
            <object>          -- built-in association known
              <symbol>        -- belongs to module(s) object belongs to
              ...

 3. As sections, objects, and symbols are processed, offset ranges are
    constructed in a straight-forward way:

      - If the symbol belongs to one or more built-in modules:
          - If we were working on the same module(s), extend the range
            to include this object
          - If we were working on another module(s), close that range,
            and start the new one
      - If the symbol does not belong to any built-in modules:
          - If we were working on a module(s) range, close that range
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

In order to create the file at build time, modules.builtin.ranges, that
contains the range of addresses for all built-in modules, there needs to
be a way to identify what code is compiled into modules.

To identify what code is compiled into modules during a kernel build,
one can look for the presence of the -DKBUILD_MODFILE and -DKBUILD_MODNAME
options in the compile command lines.  A simple grep in .*.cmd files for
those options is sufficient for this.

Unfortunately, these options are only passed when compiling C source files.
Various modules also include objects built from assembler source, and these
options are not passed in that case.

Adding $(modfile_flags) to modkern_aflags (similar to modkern_cflags), and
adding $(modname_flags) to a_flags (similar to c_flags) makes it possible
to identify which objects are compiled into modules for both C and
assembler source files.  While KBUILD_MODFILE is sufficient to generate
the modules ranges data, KBUILD_MODNAME is passed as well for consistency
with the C source code case.
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When building the Linux kernel on an aarch64 macOS based host, if we don't
specify a value for ARCH when invoking make, we default to arm and thus
multi_v7_defconfig rather than the expected arm64 and arm64's defconfig.

This is because subarch.include invokes `uname -m` which on MacOS hosts
evaluates to `arm64` but on Linux hosts evaluates to `aarch64`,

This allows us to build ARCH=arm64 natively on macOS (as in ARCH need
not be specified on an aarch64-based system).

Avoid matching arm64 by excluding it from the arm.* sed expression.
Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
Suggested-by: Nicolas Schier <nicolas@fjasle.eu>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Add more macros used for removing hash table entries.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

scripts/Makefile.lib is included not only from scripts/Makefile.build
but also from scripts/Makefile.{modfinal,package,vmlinux,vmlinux_o},
where DT build rules are not required.

Split the DT build rules out to scripts/Makefile.dtbs, and include it
only when necessary.

While I was here, I added $(DT_TMP_SCHEMA) as a prerequisite of
$(multi-dtb-y).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>

Flex and Bison are used only for host programs. Move their intermediate
target processing from scripts/Makefile.build to scripts/Makefile.host.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Various information about modules is compiled into the info sections.
For that a dedicated .mod.c file is generated by modpost for each module
and then linked into the module.
However most of the information in the .mod.c is the same for all
modules, internal and external.
Split the shared information into a dedicated source file that is
compiled once and then linked into all modules.

This avoids frequent rebuilds for all .mod.c files when using
CONFIG_LOCALVERSION_AUTO because the local version ends up in .mod.c
through UTS_RELEASE and VERMAGIC_STRING.
The modules are still relinked in this case.

The code is also easier to maintain as it's now in a proper source file
instead of an inline string literal.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Commit abe11dde ("ARC: [plat-arcfpga]: Enabling DeviceTree for
Angel4 board") changed the default built-in DTB from "skeleton" to
"angel4".

Commit fd155792 ("ARC: [plat_arcfpga]->[plat_sim]") changed it
from "angel4" to "nsim_700".
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Vineet Gupta <vgupta@kernel.org>

Remove the recently-added dependency on the truncate program for
building the kernel. truncate is not available when building the kernel
under Yocto. It could be added, but it would be better just to avoid
the unnecessary dependency.

Fixes: 1472464c ("kbuild: avoid scripts/kallsyms parsing /dev/null")
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Add a new debug package to the PKGBUILD for the pacman-pkg target. The
debug package includes the non-stripped vmlinux file with debug symbols
for kernel debugging and profiling. The file is installed at
/usr/src/debug/${pkgbase}, with a symbolic link at
/usr/lib/modules/$(uname -r)/build/vmlinux. The debug package is built
by default.
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

There are a few lines in the kbuild-language.rst document which
obliquely reference the behavior of config options without prompts.
But there is nothing in the obvious location that explicitly calls
out that users cannot edit config options unless they have a prompt.
Signed-off-by: Stephen Brennan <stephen.s.brennan@oracle.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

Commit 5ce2176b ("genksyms: adjust the output format to modpost")
stopped generating *.symversions files.

Remove the left-over from the .gitignore file and the 'clean' rule.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

With commit cda5f94e ("modpost: avoid using the alias attribute"),
only two log levels remain: LOG_WARN and LOG_ERROR. Simplify this by
making it a boolean variable.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>

objtree is defined and exported by the top-level Makefile. I prefer
not to override it.

There is no need to pass the absolute path of objtree. PKGBUILD can
detect it by itself.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by:   Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>

All build and package functions share the following commands:

  export MAKEFLAGS="${KBUILD_MAKEFLAGS}"
  cd "${objtree}"

Factor out the common code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by:   Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>

Introduce the PACMAN_EXTRAPACKAGES variable in PKGBUILD to allow users
to specify which additional packages are built by the pacman-pkg target.

Previously, the api-headers package was always included, and the headers
package was included only if CONFIG_MODULES=y. With this change, both
headers and api-headers packages are included by default. Users can now
control this behavior by setting PACMAN_EXTRAPACKAGES to a
space-separated list of desired extra packages or leaving it empty to
exclude all.

For example, to build only the base package without extras:

make pacman-pkg PACMAN_EXTRAPACKAGES=""
Signed-off-by: Jose Fernandez <jose.fernandez@linux.dev>
Reviewed-by: Peter Jung <ptr1337@cachyos.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Christian Heusel <christian@heusel.eu>
Tested-by: Christian Heusel <christian@heusel.eu>
Acked-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

This commit improves the section mismatch warning format when there is
no suitable symbol name to print.

The section mismatch warning prints the reference source in the form
of <symbol_name>+<offset> and the reference destination in the form
of <symbol_name>.

However, there are some corner cases where <symbol_name> becomes
"(unknown)", as reported in commit 23dfd914 ("modpost: fix null
pointer dereference").

In such cases, it is better to print the symbol address.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When malloc() fails, there is not much userspace programs can do.
xmalloc() is useful to bail out on a memory allocation failure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

When malloc() or realloc() fails, there is not much userspace programs
can do. xmalloc() and xrealloc() are useful to bail out on a memory
allocation failure.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>

I think x*alloc() functions are cleaner.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>