Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Jun 25, 2017
  3. Jun 21, 2017
  5. Jun 09, 2017
    • Masahiro Yamada's avatar
      kbuild: remove duplicated arch/*/include/generated/uapi include path · f8224f7f
      Masahiro Yamada authored 
      
Commit 90ac086b ("Makefile: include arch/*/include/generated/uapi
before .../generated") introduced this for bisect'ability.  The commit
chose to promote arch/*/include/generated/uapi in the search path
rather than cleaning stale headers.

After all, we found that approach was not enough, and ended up with
cleaning stale headers by commit cda2c65f ("kbuild: Remove stale
asm-generic wrappers").

So, the extra search path is no longer needed because Kbuild invokes
scripts/Makefile.asm-generic and remove stale headers before it starts
descending.

This commit is also reverting commit dc33db7c ("Kbuild: avoid
duplicate include path") because we have no more duplicated path.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      f8224f7f
  7. Jun 06, 2017
    • Masahiro Yamada's avatar
      kbuild: simplify silent build (-s) detection · 6f0fa58e
      Masahiro Yamada authored 
      
This allows to detect -s (--silent) option without checking GNU Make
version.

As commit e36aaea2 ("kbuild: Fix silent builds with make-4")
pointed out, GNU Make 4.x changed the way/order it presents the
command line options into MAKEFLAGS.

In Make 3.8x, 's' is always the first in a group of short options.
The group may be prefixed with '-' in some cases.

In Make 4.x, 's' is always the last in a group of short options.

As commit e6ac89fa ("kbuild: Correctly deal with make options
which contain an 's'") addressed, we also need to deal with long
options that contain 's', like --warn-undefined-variables.

Test cases:

[1] command line input:    make --silent
     -> MAKEFLAGS for Make 3.8x:    s
     -> MAKEFLAGS for Make 4.x :    s

[2] command line input:    make -srR
     -> MAKEFLAGS for Make 3.8x:    sRr
     -> MAKEFLAGS for Make 4.x :    rRs

[3] command line input:    make -s -rR --warn-undefined-variables
     -> MAKEFLAGS for Make 3.8x:    --warn-undefined-variables -sRr
     -> MAKEFLAGS for Make 4.x :    rRs --warn-undefined-variables

My idea to cater to all the cases more easily is to filter out long
options (--%), then search 's' with $(findstring ...).  This way will
be more future-proof even if future versions of Make put 's' in the
middle of the group.

Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6f0fa58e
  9. May 22, 2017
  11. May 17, 2017
    • Masahiro Yamada's avatar
      kbuild: skip install/check of headers right under uapi directories · 05d8cba4
      Masahiro Yamada authored 
      
Since commit 61562f98 ("uapi: export all arch specifics
directories"), "make INSTALL_HDR_PATH=$root/usr headers_install"
deletes standard glibc headers and others in $(root)/usr/include.

The cause of the issue is that headers_install now starts descending
from arch/$(hdr-arch)/include/uapi with $(root)/usr/include for its
destination when installing asm headers.  So, headers already there
are assumed to be unwanted.

When headers_install starts descending from include/uapi with
$(root)/usr/include for its destination, it works around the problem
by creating an dummy destination $(root)/usr/include/uapi, but this
is tricky.

To fix the problem in a clean way is to skip headers install/check
in include/uapi and arch/$(hdr-arch)/include/uapi because we know
there are only sub-directories in uapi directories.  A good side
effect is the empty destination $(root)/usr/include/uapi will go
away.

I am also removing the trailing slash in the headers_check target to
skip checking in arch/$(hdr-arch)/include/uapi.

Fixes: 61562f98 ("uapi: export all arch specifics directories")
Reported-by: default avatarDan Williams <dan.j.williams@intel.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: default avatarDan Williams <dan.j.williams@intel.com>
Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      05d8cba4
  13. May 13, 2017
  15. May 10, 2017
  17. May 09, 2017
  19. May 03, 2017
  21. May 01, 2017
  23. Apr 28, 2017
  25. Apr 24, 2017
  27. Apr 23, 2017
  29. Apr 18, 2017
    • Masahiro Yamada's avatar
      kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7 · 90ad4052
      Masahiro Yamada authored 
      
Arnd Bergmann reported:
  "When ftrace is enabled and we build with gcc-4.7 or older, we
  get a warning for each file on architectures that select
  CONFIG_LD_DEAD_CODE_DATA_ELIMINATION:

  warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default]
  "

Since commit c3f0d0bc ("kbuild, LLVMLinux: Add -Werror to
cc-option to support clang"), warnings are treated as errors in
cc-option checks.  CC_FLAGS_FTRACE is blindly added to KBUILD_CFLAGS,
so $(call cc-option,-ffunction-sections,) should be moved below it
in order to detect the conflict between the two options.

Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      90ad4052
  31. Apr 16, 2017
  33. Apr 12, 2017
  35. Apr 09, 2017
  37. Apr 03, 2017
  39. Mar 31, 2017
  41. Mar 26, 2017
  43. Mar 21, 2017
  45. Mar 20, 2017
  47. Mar 16, 2017
    • Arnd Bergmann's avatar
      Kbuild: use cc-disable-warning consistently for maybe-uninitialized · b334e19a
      Arnd Bergmann authored 
      
In commit a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning
for "make W=1""), I reverted another change that happened to fix a problem
with old compilers, and now we get this report again with old compilers
(prior to gcc-4.8) and GCOV enabled:

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/intel_ringbuffer.c: In function 'intel_ring_setup_status_page':
   drivers/gpu/drm/i915/intel_ringbuffer.c:438: error: 'mmio.reg' may be used uninitialized in this function
   At top level:
>> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"

The problem is that we turn off the warning conditionally in a number
of places as we should, but one of them does it unconditionally.
Instead, change it to call cc-disable-warning as we do elsewhere.

The original patch that caused it was merged into linux-4.7, then
4.8 removed the change and 4.9 brought it back, so we probably want
a backport to 4.9 once this is merged.

Use a ':=' assignment instead of '=' to force the cc-disable-warning
call to only be evaluated once instead of every time.

Cc: stable@vger.kernel.org
Fixes: a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"")
Fixes: e72e2dfe ("gcov: disable -Wmaybe-uninitialized warning")
Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      b334e19a
  49. Mar 14, 2017
  51. Mar 12, 2017
  53. Mar 11, 2017
  55. Mar 05, 2017
  57. Feb 20, 2017
  59. Feb 19, 2017
  61. Feb 15, 2017
  63. Feb 12, 2017
  65. Feb 05, 2017
  67. Feb 03, 2017
  69. Jan 29, 2017
  71. Jan 26, 2017
  73. Jan 22, 2017