1. 10 7月, 2017 2 次提交
  2. 03 7月, 2017 2 次提交
  3. 30 6月, 2017 1 次提交
    • N
      kbuild: handle libs-y archives separately from built-in.o archives · 3a166fc2
      Nicholas Piggin 提交于
      The thin archives build currently puts all lib.a and built-in.o
      files together and links them with --whole-archive.
      
      This works because thin archives can recursively refer to thin
      archives. However some architectures include libgcc.a, which may
      not be a thin archive, or it may not be constructed with the "P"
      option, in which case its contents do not get linked correctly.
      
      So don't pull .a libs into the root built-in.o archive. These
      libs should already have symbol tables and indexes built, so they
      can be direct linker inputs. Move them out of the --whole-archive
      option, which restore the conditional linking behaviour of lib.a
      to thin archives builds.
      Signed-off-by: NNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      3a166fc2
  4. 26 6月, 2017 1 次提交
  5. 25 6月, 2017 1 次提交
  6. 24 6月, 2017 1 次提交
  7. 22 6月, 2017 1 次提交
  8. 19 6月, 2017 1 次提交
  9. 12 6月, 2017 1 次提交
  10. 10 6月, 2017 1 次提交
    • M
      kbuild: remove duplicated arch/*/include/generated/uapi include path · f8224f7f
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      f8224f7f
  11. 06 6月, 2017 2 次提交
    • C
      Kbuild: tiny correction on `make help` · 9ba26a72
      Cao jin 提交于
      The help info of `make C=1` is little confusing, make it clear.
      Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      9ba26a72
    • M
      kbuild: simplify silent build (-s) detection · 6f0fa58e
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      6f0fa58e
  12. 05 6月, 2017 1 次提交
  13. 29 5月, 2017 1 次提交
  14. 22 5月, 2017 1 次提交
  15. 18 5月, 2017 1 次提交
    • M
      kbuild: skip install/check of headers right under uapi directories · 05d8cba4
      Masahiro Yamada 提交于
      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: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: NDan Williams <dan.j.williams@intel.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      05d8cba4
  16. 16 5月, 2017 1 次提交
  17. 14 5月, 2017 1 次提交
  18. 10 5月, 2017 1 次提交
  19. 09 5月, 2017 1 次提交
  20. 03 5月, 2017 1 次提交
  21. 01 5月, 2017 1 次提交
  22. 28 4月, 2017 1 次提交
  23. 25 4月, 2017 1 次提交
  24. 24 4月, 2017 1 次提交
  25. 23 4月, 2017 2 次提交
  26. 18 4月, 2017 1 次提交
    • M
      kbuild: avoid conflict between -ffunction-sections and -pg on gcc-4.7 · 90ad4052
      Masahiro Yamada 提交于
      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: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      90ad4052
  27. 17 4月, 2017 1 次提交
  28. 13 4月, 2017 1 次提交
  29. 10 4月, 2017 1 次提交
  30. 03 4月, 2017 1 次提交
  31. 31 3月, 2017 1 次提交
  32. 27 3月, 2017 1 次提交
  33. 22 3月, 2017 2 次提交
  34. 20 3月, 2017 1 次提交
  35. 17 3月, 2017 1 次提交
    • A
      Kbuild: use cc-disable-warning consistently for maybe-uninitialized · b334e19a
      Arnd Bergmann 提交于
      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: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      b334e19a