1. 13 Dec, 2018 1 commit
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 51d137ca
      Nick Desaulniers authored
      (commit 86a9df59 upstream)
      I was not seeing my linker flags getting added when using ld-option when
      cross compiling with Clang. Upon investigation, this seems to be due to
      a difference in how GCC vs Clang handle cross compilation.
      GCC is configured at build time to support one backend, that is implicit
      when compiling.  Clang is explicit via the use of `-target <triple>` and
      ships with all supported backends by default.
      GNU Make feature test macros that compile then link will always fail
      when cross compiling with Clang unless Clang's triple is passed along to
      the compiler. For example:
      $ clang -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      unknown architecture of input file `temp.o' is incompatible with
      aarch64 output
      warning: cannot find entry symbol _start; defaulting to
      $ echo $?
      $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      warning: cannot find entry symbol _start; defaulting to 00000000004002e4
      $ echo $?
      This causes conditional checks that invoke $(CC) without the target
      triple, then $(LD) on the result, to always fail.
      Suggested-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      [ND: readjusted for context]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 08 Dec, 2018 2 commits
  3. 23 Nov, 2018 7 commits
  4. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · 48a90a9e
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ]
      If Make gets a fatal signal while a shell is executing, it may delete
      the target file that the recipe was supposed to update.  This is needed
      to make sure that it is remade from scratch when Make is next run; if
      Make is interrupted after the recipe has begun to write the target file,
      it results in an incomplete file whose time stamp is newer than that
      of the prerequisites files.  Make automatically deletes the incomplete
      file on interrupt unless the target is marked .PRECIOUS.
      The situation is just the same as when the shell fails for some reasons.
      Usually when a recipe line fails, if it has changed the target file at
      all, the file is corrupted, or at least it is not completely updated.
      Yet the file’s time stamp says that it is now up to date, so the next
      time Make runs, it will not try to update that file.
      However, Make does not cater to delete the incomplete target file in
      this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
      to request it.
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      Please note .DELETE_ON_ERROR is not effective for phony targets.
      The external module building should never ever touch the kernel tree.
      The following recipe fails if include/generated/autoconf.h is missing.
      However, include/config/auto.conf is not deleted since it is a phony
       PHONY += include/config/auto.conf
               $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
               echo >&2;                                                       \
               echo >&2 "  ERROR: Kernel configuration is invalid.";           \
               echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
               echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
               echo >&2 ;                                                      \
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 15 Sep, 2018 2 commits
  6. 17 Aug, 2018 2 commits
  7. 11 Jul, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · b5d7d7d9
      Rasmus Villemoes authored
      commit 9564a8cf422d7b58f6e857e3546d346fa970191e upstream.
      I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
      already the objtool build broke with
      orc_dump.c: In function ‘orc_dump’:
      orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
        if (elf_getshdrnum(elf, &nr_sections)) {
      Turns out that with that new Make, the backslash was not removed, so cpp
      didn't see a #include directive, grep found nothing, and
      -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
      Now, that new Make behaviour is documented in their NEWS file:
        * WARNING: Backward-incompatibility!
          Number signs (#) appearing inside a macro reference or function invocation
          no longer introduce comments and should not be escaped with backslashes:
          thus a call such as:
            foo := $(shell echo '#')
          is legal.  Previously the number sign needed to be escaped, for example:
            foo := $(shell echo '\#')
          Now this latter will resolve to "\#".  If you want to write makefiles
          portable to both versions, assign the number sign to a variable:
            C := \#
            foo := $(shell echo '$C')
          This was claimed to be fixed in 3.81, but wasn't, for some reason.
          To detect this change search for 'nocomment' in the .FEATURES variable.
      This also fixes up the two make-cmd instances to replace # with $(pound)
      rather than with \#. There might very well be other places that need
      similar fixup in preparation for whatever future Make release contains
      the above change, but at least this builds an x86_64 defconfig with the
      new make.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 13 Jun, 2018 2 commits
    • Josh Poimboeuf's avatar
      objtool: Fix gcov check for older versions of GCC · 23873aed
      Josh Poimboeuf authored
      commit 867ac9d7 upstream.
      Objtool tries to silence 'unreachable instruction' warnings when it
      detects gcov is enabled, because gcov produces a lot of unreachable
      instructions and they don't really matter.
      However, the 0-day bot is still reporting some unreachable instruction
      warnings with CONFIG_GCOV_KERNEL=y on GCC 4.6.4.
      As it turns out, objtool's gcov detection doesn't work with older
      versions of GCC because they don't create a bunch of symbols with the
      'gcov.' prefix like newer versions of GCC do.
      Move the gcov check out of objtool and instead just create a new
      '--no-unreachable' flag which can be passed in by the kernel Makefile
      when CONFIG_GCOV_KERNEL is defined.
      Also rename the 'nofp' variable to 'no_fp' for consistency with the new
      'no_unreachable' variable.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 9cfffb11 ("objtool: Skip all "unreachable instruction" warnings for gcov kernels")
      Link: http://lkml.kernel.org/r/c243dc78eb2ffdabb6e927844dea39b6033cd395.1500939244.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      [just Makefile.build as the other parts of this patch already applied - gregkh]
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Nathan Chancellor's avatar
      kconfig: Avoid format overflow warning from GCC 8.1 · 1ec1dfba
      Nathan Chancellor authored
      commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream.
      In file included from scripts/kconfig/zconf.tab.c:2485:
      scripts/kconfig/confdata.c: In function ‘conf_write’:
      scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
        sprintf(newname, "%s%s", dirname, basename);
      scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes
        sprintf(newname, "%s%s", dirname, basename);
      scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097
        sprintf(newname, "%s%s", dirname, basename);
      scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=]
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
      scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097
         sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid());
      Increase the size of tmpname and newname to make GCC happy.
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  9. 30 May, 2018 5 commits
  10. 13 Apr, 2018 1 commit
  11. 18 Mar, 2018 1 commit
    • James Hogan's avatar
      kbuild: Handle builtin dtb file names containing hyphens · 333cdd17
      James Hogan authored
      commit 55fe6da9 upstream.
      cmd_dt_S_dtb constructs the assembly source to incorporate a devicetree
      FDT (that is, the .dtb file) as binary data in the kernel image. This
      assembly source contains labels before and after the binary data. The
      label names incorporate the file name of the corresponding .dtb file.
      Hyphens are not legal characters in labels, so .dtb files built into the
      kernel with hyphens in the file name result in errors like the
      bcm3368-netgear-cvg834g.dtb.S: Assembler messages:
      bcm3368-netgear-cvg834g.dtb.S:5: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:5: Error: junk at end of line, first unrecognized character is `-'
      bcm3368-netgear-cvg834g.dtb.S:6: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_begin:'
      bcm3368-netgear-cvg834g.dtb.S:8: Error: unrecognized opcode `__dtb_bcm3368-netgear-cvg834g_end:'
      bcm3368-netgear-cvg834g.dtb.S:9: Error: : no such section
      bcm3368-netgear-cvg834g.dtb.S:9: Error: junk at end of line, first unrecognized character is `-'
      Fix this by updating cmd_dt_S_dtb to transform all hyphens from the file
      name to underscores when constructing the labels.
      As of v4.16-rc2, 1139 .dts files across ARM64, ARM, MIPS and PowerPC
      contain hyphens in their names, but the issue only currently manifests
      on Broadcom MIPS platforms, as that is the only place where such files
      are built into the kernel. For example when CONFIG_DT_NETGEAR_CVG834G=y,
      or on BMIPS kernels when the dtbs target is used (in the latter case it
      admittedly shouldn't really build all the dtb.o files, but thats a
      separate issue).
      Fixes: 69583551 ("MIPS: BMIPS: rename bcm96358nb4ser to bcm6358-neufbox4-sercom")
      Signed-off-by: default avatarJames Hogan <jhogan@kernel.org>
      Reviewed-by: default avatarFrank Rowand <frowand.list@gmail.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Michal Marek <michal.lkml@markovi.net>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: <stable@vger.kernel.org> # 4.9+
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  12. 25 Feb, 2018 1 commit
    • Will Deacon's avatar
      scripts/kernel-doc: Don't fail with status != 0 if error encountered with -none · e985f5a9
      Will Deacon authored
      [ Upstream commit e814bccb ]
      My bisect scripts starting running into build failures when trying to
      compile 4.15-rc1 with the builds failing with things like:
      drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:2078: error: Cannot parse struct or union!
      The line in question is actually just a #define, but after some digging
      it turns out that my scripts pass W=1 and since commit 3a025e1d
      ("Add optional check for bad kernel-doc comments") that results in
      kernel-doc running on each source file. The file in question has a
      badly formatted comment immediately before the #define:
       * struct brcmf_skbuff_cb reserves first two bytes in sk_buff::cb for
       * bus layer usage.
      which causes the regex in dump_struct to fail (lack of braces following
      struct declaration) and kernel-doc returns 1, which causes the build
      to fail.
      Fix the issue by always returning 0 from kernel-doc when invoked with
      -none. It successfully generates no documentation, and prints out any
      Cc: Matthew Wilcox <mawilcox@microsoft.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  13. 13 Feb, 2018 1 commit
  14. 23 Jan, 2018 1 commit
  15. 17 Jan, 2018 1 commit
  16. 14 Dec, 2017 3 commits
  17. 21 Jul, 2017 1 commit
  18. 12 Jan, 2017 1 commit
  19. 09 Jan, 2017 2 commits
  20. 06 Jan, 2017 1 commit
  21. 01 Dec, 2016 1 commit
  22. 11 Nov, 2016 2 commits
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warnings by default · 4324cb23
      Arnd Bergmann authored
      Previously the warnings were added back at the W=1 level and above, this
      now turns them on again by default, assuming that we have addressed all
      warnings and again have a clean build for v4.10.
      I found a number of new warnings in linux-next already and submitted
      bugfixes for those.  Hopefully they are caught by the 0day builder in
      the future as soon as this patch is merged.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Arnd Bergmann's avatar
      Kbuild: enable -Wmaybe-uninitialized warning for "make W=1" · a76bcf55
      Arnd Bergmann authored
      Traditionally, we have always had warnings about uninitialized variables
      enabled, as this is part of -Wall, and generally a good idea [1], but it
      also always produced false positives, mainly because this is a variation
      of the halting problem and provably impossible to get right in all cases
      Various people have identified cases that are particularly bad for false
      positives, and in commit e74fc973 ("Turn off -Wmaybe-uninitialized
      when building with -Os"), I turned off the warning for any build that
      was done with CC_OPTIMIZE_FOR_SIZE.  This drastically reduced the number
      of false positive warnings in the default build but unfortunately had
      the side effect of turning the warning off completely in 'allmodconfig'
      builds, which in turn led to a lot of warnings (both actual bugs, and
      remaining false positives) to go in unnoticed.
      With commit 877417e6 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
      definition") enabled the warning again for allmodconfig builds in v4.7
      and in v4.8-rc1, I had finally managed to address all warnings I get in
      an ARM allmodconfig build and most other maybe-uninitialized warnings
      for ARM randconfig builds.
      However, commit 6e8d666e ("Disable "maybe-uninitialized" warning
      globally") was merged at the same time and disabled it completely for
      all configurations, because of false-positive warnings on x86 that I had
      not addressed until then.  This caused a lot of actual bugs to get
      merged into mainline, and I sent several dozen patches for these during
      the v4.9 development cycle.  Most of these are actual bugs, some are for
      correct code that is safe because it is only called under external
      constraints that make it impossible to run into the case that gcc sees,
      and in a few cases gcc is just stupid and finds something that can
      obviously never happen.
      I have now done a few thousand randconfig builds on x86 and collected
      all patches that I needed to address every single warning I got (I can
      provide the combined patch for the other warnings if anyone is
      interested), so I hope we can get the warning back and let people catch
      the actual bugs earlier.
      This reverts the change to disable the warning completely and for now
      brings it back at the "make W=1" level, so we can get it merged into
      mainline without introducing false positives.  A follow-up patch enables
      it on all levels unless some configuration option turns it off because
      of false-positives.
      Link: https://rusty.ozlabs.org/?p=232 [1]
      Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>