Skip to content

C
clone-Linux

gsplhtlxg / clone-Linux

通知 2
Star 0
Fork 1
C
clone-Linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 08 7月, 2019 4 次提交
  3. 01 7月, 2019 4 次提交
    • M
      fixdep: check return value of printf() and putchar() · 6f9ac9f4
      由 Masahiro Yamada 提交于 
      When there is not enough space on your storage device, the build will
fail with 'No space left on device' error message.

The reason is obvious from the message, so you will free up some disk
space, then you will resume the build.

However, sometimes you may still see a mysterious error message:

  unterminated call to function 'wildcard': missing ')'.

If you run out of the disk space, fixdep may end up with generating
incomplete .*.cmd files.

For example, if the disk-full error occurs while fixdep is running
print_dep(), the .*.cmd might be truncated like this:

   $(wildcard include/config/

When you run 'make' next time, this broken .*.cmd will be included,
then Make will terminate parsing since it is a wrong syntax.

Once this happens, you need to run 'make clean' or delete the broken
.*.cmd file manually.

Even if you do not see any error message, the .*.cmd files after any
error could be potentially incomplete, and unreliable. You may miss
the re-compilation due to missing header dependency.

If printf() cannot output the string for disk shortage or whatever
reason, it returns a negative value, but currently fixdep does not
check it at all. Consequently, fixdep *successfully* generates a
broken .*.cmd file. Make never notices that since fixdep exits with 0,
which means success.

Given the intended usage of fixdep, it must respect the return value
of not only malloc(), but also printf() and putchar().

This seems a long-standing issue since the introduction of fixdep.

In old days, Kbuild tried to provide an extra safety by letting fixdep
output to a temporary file and renaming it after everything is done:

  scripts/basic/fixdep $(depfile) $@ '$(make-cmd)' > $(dot-target).tmp;\
  rm -f $(depfile);                                                    \
  mv -f $(dot-target).tmp $(dot-target).cmd)

It was no help to avoid the current issue; fixdep successfully created
a truncated tmp file, which would be renamed to a .*.cmd file.

This problem should be fixed by propagating the error status to the
build system because:

[1] Since commit 9c2af1c7 ("kbuild: add .DELETE_ON_ERROR special
    target"), Make will delete the target automatically on any failure
    in the recipe.

[2] Since commit 392885ee ("kbuild: let fixdep directly write to
    .*.cmd files"), .*.cmd file is included only when the corresponding
    target already exists.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6f9ac9f4
    • M
      kbuild: save $(strip ...) for calling if_changed and friends · c2341e2a
      由 Masahiro Yamada 提交于 
      The string returned by $(filter-out ...) does not contain any leading
or trailing spaces.

With the previous commit, 'any-prereq' no longer contains any
excessive spaces.

Nor does 'cmd-check' since it expands to a $(filter-out ...) call.

So, only the space that matters is the one between 'any-prereq'
and 'cmd-check'.

By removing it from the code, we can save $(strip ...) evaluation.
This refactoring is possible because $(any-prereq)$(cmd-check) is only
passed to the first argument of $(if ...), so we are only interested
in whether or not it is empty.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      c2341e2a
    • M
      kbuild: save $(strip ...) for calling any-prepreq · 93f31bbd
      由 Masahiro Yamada 提交于 
      The string returned by $(filter-out ...) does not contain any leading
or trailing spaces.

So, only the space that matters is the one between

  $(filter-out $(PHONY),$?)

and

  $(filter-out $(PHONY) $(wildcard $^),$^)

By removing it from the code, we can save $(strip ...) evaluation.
This refactoring is possible because $(any-prereq) is only passed to
the first argument of $(if ...), so we are only interested in whether
or not it is empty.

This is also the prerequisite for the next commit.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      93f31bbd
    • M
      kbuild: rename arg-check to cmd-check · 50bcca6a
      由 Masahiro Yamada 提交于 
      I prefer 'cmd-check' for consistency.

We have 'echo-cmd', 'cmd', 'cmd_and_fixdep', etc. in this file.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      50bcca6a
  5. 24 6月, 2019 4 次提交
  7. 15 6月, 2019 8 次提交
    • J
      kbuild: add support for ensuring headers are self-contained · e846f0dc
      由 Jani Nikula 提交于 
      Sometimes it's useful to be able to explicitly ensure certain headers
remain self-contained, i.e. that they are compilable as standalone
units, by including and/or forward declaring everything they depend on.

Add special target header-test-y where individual Makefiles can add
headers to be tested if CONFIG_HEADER_TEST is enabled. This will
generate a dummy C file per header that gets built as part of extra-y.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      e846f0dc
    • M
      kbuild: deb-pkg: do not run headers_check · 0315bb7a
      由 Masahiro Yamada 提交于 
      It is absolutely fine to add extra sanity checks in package scripts,
but it is not necessary to do so.

This is already covered by the daily compile-testing (0day bot etc.)
because headers_check is run as a part of the normal build process
when CONFIG_HEADERS_CHECK=y.

Replace it with the newly-added "make headers".
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      0315bb7a
    • M
      kbuild: simplify scripts/headers_install.sh · 555187a8
      由 Masahiro Yamada 提交于 
      Now that headers_install.sh is invoked per file, remove the for-loop
in the shell script.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      555187a8
    • M
      kbuild: move hdr-inst shorthand to top Makefile · a5bae54c
      由 Masahiro Yamada 提交于 
      Now that hdr-inst is used only in the top Makefile, move it there
from scripts/Kbuild.include.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      a5bae54c
    • M
      kbuild: re-implement Makefile.headersinst without recursion · d5470d14
      由 Masahiro Yamada 提交于 
      Since commit fcc8487d ("uapi: export all headers under uapi
directories"), the headers in uapi directories are all exported by
default although exceptional cases are still allowed by the syntax
'no-export-headers'.

The traditional directory descending has been kept (in a somewhat
hacky way), but it is actually unneeded.

Get rid of it to simplify the code.

Also, handle files one by one instead of the previous per-directory
processing. This will emit much more log, but I like it.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      d5470d14
    • M
      kbuild: add 'headers' target to build up uapi headers in usr/include · 59b2bd05
      由 Masahiro Yamada 提交于 
      In Linux build system, build targets and installation targets are
separated.

Examples are:

 - 'make vmlinux' -> 'make install'
 - 'make modules' -> 'make modules_install'
 - 'make dtbs'    -> 'make dtbs_install'
 - 'make vdso'    -> 'make vdso_install'

The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.

We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.

If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.

Anyway, I believe it makes sense to split the header installation into
two stages.

 [1] 'make headers'
    Process headers in uapi directories by scripts/headers_install.sh
    and copy them to usr/include

 [2] 'make headers_install'
    Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include

For the backward compatibility, 'headers_install' depends on 'headers'.

Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.

Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.

Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      59b2bd05
    • M
      kbuild: remove build_unifdef target in scripts/Makefile · 2b8481be
      由 Masahiro Yamada 提交于 
      Since commit 2aedcd09 ("kbuild: suppress annoying "... is up to date."
message"), if_changed and friends nicely suppress "is up to date" messages.

We do not need per-Makefile tricks.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      2b8481be
    • M
      kbuild: remove headers_{install,check}_all · f3c8d4c7
      由 Masahiro Yamada 提交于 
      headers_install_all does not make much sense any more because different
architectures export different set of uapi/linux/ headers. As you see
in include/uapi/linux/Kbuild, the installation of a.out.h, kvm.h, and
kvm_para.h is arch-dependent. So, headers_install_all repeats the
installation/removal of them.

If somebody really thinks it is useful to do headers_install for all
architectures, it would be possible by small shell-scripting, but
the top Makefile does not have to provide entry targets just for that
purpose.
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: NSam Ravnborg <sam@ravnborg.org>
      f3c8d4c7
  9. 09 6月, 2019 1 次提交
    • M
      kbuild: Remove -Waggregate-return from scripts/Makefile.extrawarn · 869ee58b
      由 Mathieu Malaterre 提交于 
      It makes little sense to pass -Waggregate-return these days since large
part of the linux kernel rely on returning struct(s). For instance:

  ../include/linux/timekeeping.h: In function 'show_uptime':
  ../include/linux/ktime.h:91:34: error: function call has aggregate value [-Werror=aggregate-return]
   #define ktime_to_timespec64(kt)  ns_to_timespec64((kt))
                                    ^~~~~~~~~~~~~~~~~~~~~~
  ../include/linux/timekeeping.h:166:8: note: in expansion of macro 'ktime_to_timespec64'
    *ts = ktime_to_timespec64(ktime_get_coarse_boottime());

Remove this warning from W=2 completely.
Signed-off-by: NMathieu Malaterre <malat@debian.org>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      869ee58b
  11. 07 6月, 2019 1 次提交
    • M
      kbuild: use more portable 'command -v' for cc-cross-prefix · 913ab978
      由 Masahiro Yamada 提交于 
      To print the pathname that will be used by shell in the current
environment, 'command -v' is a standardized way. [1]

'which' is also often used in scripts, but it is less portable.

When I worked on commit bd55f96f ("kbuild: refactor cc-cross-prefix
implementation"), I was eager to use 'command -v' but it did not work.
(The reason is explained below.)

I kept 'which' as before but got rid of '> /dev/null 2>&1' as I
thought it was no longer needed. Sorry, I was wrong.

It works well on my Ubuntu machine, but Alexey Brodkin reports noisy
warnings on CentOS7 when 'which' fails to find the given command in
the PATH environment.

  $ which foo
  which: no foo in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin)

Given that behavior of 'which' depends on system (and it may not be
installed by default), I want to try 'command -v' once again.

The specification [1] clearly describes the behavior of 'command -v'
when the given command is not found:

  Otherwise, no output shall be written and the exit status shall reflect
  that the name was not found.

However, we need a little magic to use 'command -v' from Make.

$(shell ...) passes the argument to a subshell for execution, and
returns the standard output of the command.

Here is a trick. GNU Make may optimize this by executing the command
directly instead of forking a subshell, if no shell special characters
are found in the command and omitting the subshell will not change the
behavior.

In this case, no shell special character is used. So, Make will try
to run it directly. However, 'command' is a shell-builtin command,
then Make would fail to find it in the PATH environment:

  $ make ARCH=m68k defconfig
  make: command: Command not found
  make: command: Command not found
  make: command: Command not found

In fact, Make has a table of shell-builtin commands because it must
ask the shell to execute them.

Until recently, 'command' was missing in the table.

This issue was fixed by the following commit:

| commit 1af314465e5dfe3e8baa839a32a72e83c04f26ef
| Author: Paul Smith <psmith@gnu.org>
| Date:   Sun Nov 12 18:10:28 2017 -0500
|
|     * job.c: Add "command" as a known shell built-in.
|
|     This is not a POSIX shell built-in but it's common in UNIX shells.
|     Reported by Nick Bowler <nbowler@draconx.ca>.

Because the latest release is GNU Make 4.2.1 in 2016, this commit is
not included in any released versions. (But some distributions may
have back-ported it.)

We need to trick Make to spawn a subshell. There are various ways to
do so:

 1) Use a shell special character '~' as dummy

    $(shell : ~; command -v $(c)gcc)

 2) Use a variable reference that always expands to the empty string
    (suggested by David Laight)

    $(shell command$${x:+} -v $(c)gcc)

 3) Use redirect

    $(shell command -v $(c)gcc 2>/dev/null)

I chose 3) to not confuse people. The stderr would not be polluted
anyway, but it will provide extra safety, and is easy to understand.

Tested on Make 3.81, 3.82, 4.0, 4.1, 4.2, 4.2.1

[1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/command.html

Fixes: bd55f96f ("kbuild: refactor cc-cross-prefix implementation")
Cc: linux-stable <stable@vger.kernel.org> # 5.1
Reported-by: NAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: NAlexey Brodkin <abrodkin@synopsys.com>
      913ab978
  13. 05 6月, 2019 10 次提交
  15. 02 6月, 2019 2 次提交
  17. 31 5月, 2019 6 次提交