Add LLVM + CLANG 18 support #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit 8708e13c6a0600625eea3aebd027c0715a5d2bb2 upstream. Add keyword support so that our mailing list gets cc'ed for clang/llvm patches. We're pretty active on our mailing list so far as code review. There are numerous Googlers like myself that are paid to support building the Linux kernel with Clang and LLVM. Link: http://lkml.kernel.org/r/20190620001907.255803-1-ndesaulniers@google.com Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: Joe Perches <joe@perches.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fcf1b6a35c16ac500fa908a4022238e5d666eabf upstream.
added to kbuild documentation. Provides more official info on building
kernels with Clang and LLVM than our wiki.
Suggested-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
[nd: hunk against Documentation/kbuild/index.rst dropped due to not backporting
commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0f44fbc162b737ff6251ae248184390ae2279fee upstream.
The tool is called llvm-size, not llvm-objsize.
Fixes: fcf1b6a35c16 ("Documentation/llvm: add documentation on building w/ Clang/LLVM")
Signed-off-by: Fangrui Song <maskray@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit e00d8880481497474792d28c14479a9fb6752046 ]
Commit c3ff2a5193fa ("powerpc/32: add stack protector support")
caused kernel panic on PowerPC when an external module is used with
CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
for the external module build.
Commit e07db28eea38 ("kbuild: fix single target build for external
module") turned it into a build error because the 'prepare' target is
now executed but the 'prepare0' target is missing for the external
module build.
External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is
also broken in the same way.
Move 'PHONY += prepare0' to the common place. GNU Make is fine with
missing rule for phony targets. I also removed the comment which is
wrong irrespective of this commit.
I minimize the change so it can be easily backported to 4.20.x
To fix v4.20, please backport e07db28eea38 ("kbuild: fix single target
build for external module"), and then this commit.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891
Fixes: e07db28eea38 ("kbuild: fix single target build for external module")
Fixes: c3ff2a5193fa ("powerpc/32: add stack protector support")
Fixes: 189af4657186 ("ARM: smp: add support for per-task stack canaries")
Fixes: 0a1213fa7432 ("arm64: enable per-task stack canaries")
Cc: linux-stable <stable@vger.kernel.org> # v4.20
Reported-by: Samuel Holland <samuel@sholland.org>
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7bac98707f65b93bf994ef4e99b1eb9e7dbb9c32 upstream. Define and export OBJSIZE variable for "size" tool from binutils to be used in architecture specific Makefiles (naming the variable just "SIZE" would be too risky). In particular this tool is useful to perform checks that early boot code is not using bss section (which might have not been zeroed yet or intersects with initrd or other files boot loader might have put right after the linux kernel). Link: http://lkml.kernel.org/r/patch-1.thread-2257a1.git-188f5a3d81d5.your-ad-here.call-01565088755-ext-5120@work.hours Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eefb8c124fd969e9a174ff2bedff86aa305a7438 upstream. Introduce a new READELF variable to top-level Makefile, so the name of readelf binary can be specified. Before this change the name of the binary was hardcoded to "$(CROSS_COMPILE)readelf" which might not be present for every toolchain. This allows to build with LLVM Object Reader by using make parameter READELF=llvm-readelf. Link: ClangBuiltLinux/linux#771 Signed-off-by: Dmitry Golovin <dima@golovin.in> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…firmware commit 63b903dfebdea92aa92ad337d8451a6fbfeabf9d upstream. As far as I understood from the Kconfig help text, this build rule is used to rebuild the driver firmware, which runs on an old m68k-based chip. So, you need m68k tools for the firmware rebuild. wanxl.c is a PCI driver, but CONFIG_M68K does not select CONFIG_HAVE_PCI. So, you cannot enable CONFIG_WANXL_BUILD_FIRMWARE for ARCH=m68k. In other words, ifeq ($(ARCH),m68k) is false here. I am keeping the dead code for now, but rebuilding the firmware requires 'as68k' and 'ld68k', which I do not have in hand. Instead, the kernel.org m68k GCC [1] successfully built it. Allowing a user to pass in CROSS_COMPILE_M68K= is handier. [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/9.2.0/x86_64-gcc-9.2.0-nolibc-m68k-linux.tar.xz Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…rmware commit 734f3719d3438f9cc181d674c33ca9762e9148a1 upstream. The firmware source, wanxlfw.S, is currently compiled by the combo of $(CPP) and $(M68KAS). This is not what we usually do for compiling *.S files. In fact, this Makefile is the only user of $(AS) in the kernel build. Instead of combining $(CPP) and (AS) from different tool sets, using $(M68KCC) as an assembler driver is simpler, and saner. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aa824e0c962b532d5073cbb41b2efcd6f5e72bae upstream.
As commit 5ef872636ca7 ("kbuild: get rid of misleading $(AS) from
documents") noted, we rarely use $(AS) directly in the kernel build.
Now that the only/last user of $(AS) in drivers/net/wan/Makefile was
converted to $(CC), $(AS) is no longer used in the build process.
You can still pass in AS=clang, which is just a switch to turn on
the LLVM integrated assembler.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
[nd: conflict in exported vars list from not backporting commit
e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e20e47c70f810d678d02941fa3c671209c4ca97 upstream. The 'AS' variable is unused for building the kernel. Only the remaining usage is to turn on the integrated assembler. A boolean flag is a better fit for this purpose. AS=clang was added for experts. So, I replaced it with LLVM_IAS=1, breaking the backward compatibility. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0d1c951ef08ed24f35129267e3595d86f57f5d3 upstream. As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy. Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable. Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default. We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools: https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43 Some items discussed, but not adopted: - LLVM_DIR When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful. CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ... However, we can handle this by modifying PATH. So, we decided to not do this. - LLVM_SUFFIX Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix. CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ... will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> [nd: conflict in exported vars list from not backporting commit e83b9f55448a ("kbuild: add ability to generate BTF type info for vmlinux")] [nd: hunk against Documentation/kbuild/kbuild.rst dropped due to not backporting commit cd238effefa2 ("docs: kbuild: convert docs to ReST and rename to *.rst")] Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clang's integrated assembler produces the warning for assembly files: warning: DWARF2 only supports one section per compilation unit If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch. Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64. Reported-by: Dmitry Golovin <dima@golovin.in> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Dmitry Golovin <dima@golovin.in> Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Cc: <stable@vger.kernel.org> Link: ClangBuiltLinux/linux#716 Bug: 141693040 Link: https://lore.kernel.org/lkml/20201109183528.1391885-1-ndesaulniers@google.com/ Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Change-Id: I55c8ad79dfeaae478c8de52d484e76fb2e37c194
commit 4d6ffa27b8e5116c0abb318790fd01d4e12d75e6 upstream. Commit 393f203 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") added .weak directives to arch/x86/lib/mem*_64.S instead of changing the existing ENTRY macros to WEAK. This can lead to the assembly snippet .weak memcpy ... .globl memcpy which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Commit ef1e03152cb0 ("x86/asm: Make some functions local") changed ENTRY in arch/x86/lib/memcpy_64.S to SYM_FUNC_START_LOCAL, which was ineffective due to the preceding .weak directive. Use the appropriate SYM_FUNC_START_WEAK instead. Fixes: 393f203 ("x86_64: kasan: add interceptors for memset/memmove/memcpy functions") Fixes: ef1e03152cb0 ("x86/asm: Make some functions local") Reported-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Fangrui Song <maskray@google.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/20201103012358.168682-1-maskray@google.com [nd: backport due to missing commit e9b9d020c487 ("x86/asm: Annotate aliases") commit ffedeeb780dc ("linkage: Introduce new macros for assembler symbols")] Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e0d5896bd356cd577f9710a02d7a474cdf58426b upstream. Unlike gcc, clang considers each inline assembly block to be independent and therefore, when using the integrated assembler for inline assembly, any preambles that enable features must be repeated in each block. This change defines __LSE_PREAMBLE and adds it to each inline assembly block that has LSE instructions, which allows them to be compiled also with clang's assembler. Link: ClangBuiltLinux/linux#671 Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Andrew Murray <andrew.murray@arm.com> Tested-by: Kees Cook <keescook@chromium.org> Reviewed-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Will Deacon <will@kernel.org> [nd: backport adjusted due to missing: commit addfc38672c7 ("arm64: atomics: avoid out-of-line ll/sc atomics")] Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 885480b084696331bea61a4f7eba10652999a9c1 upstream. Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D100581 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> [nc: Backport, workaround lack of e2079e93f562 in older branches] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a52f8a59aef46b59753e583bf4b28fccb069ce64 upstream. Clang has never correctly compiled the FORTIFY_SOURCE defenses due to a couple bugs: Eliding inlines with matching __builtin_* names https://bugs.llvm.org/show_bug.cgi?id=50322 Incorrect __builtin_constant_p() of some globals https://bugs.llvm.org/show_bug.cgi?id=41459 In the process of making improvements to the FORTIFY_SOURCE defenses, the first (silent) bug (coincidentally) becomes worked around, but exposes the latter which breaks the build. As such, Clang must not be used with CONFIG_FORTIFY_SOURCE until at least latter bug is fixed (in Clang 13), and the fortify routines have been rearranged. Update the Kconfig to reflect the reality of the current situation. Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/lkml/CAKwvOd=A+ueGV2ihdy5GtgR2fQbcXjjAtVxv3=cPjffpebZB7A@mail.gmail.com Cc: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is _not_ an upstream commit and just for 4.19.y only. It is based
on commit 32ef9e5054ec0321b9336058c58ec749e9c6b0fe upstream.
Alexey reported that the fraction of unknown filename instances in
kallsyms grew from ~0.3% to ~10% recently; Bill and Greg tracked it down
to assembler defined symbols, which regressed as a result of:
commit b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1")
In that commit, I allude to restoring debug info for assembler defined
symbols in a follow up patch, but it seems I forgot to do so in
commit a66049e2cf0e ("Kbuild: make DWARF version a choice")
Fixes: b8a9092330da ("Kbuild: do not emit debug info for assembly with LLVM_IAS=1")
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c435c166dcf526ac827bc964d82cc0d5e7a1fd0b ]
Zhihao sent a patch but it made llvm__compile_bpf() return what
asprintf() returns on error, which is just -1, but since this function
returns -errno, fix it by returning -ENOMEM for this case instead.
Fixes: cb76371441d098 ("perf llvm: Allow passing options to llc ...")
Fixes: 5eab5a7ee032ac ("perf llvm: Display eBPF compiling command ...")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reported-by: Zhihao Cheng <chengzhihao1@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Yu Kuai <yukuai3@huawei.com>
Cc: clang-built-linux@googlegroups.com
Link: http://lore.kernel.org/lkml/20210609115945.2193194-1-chengzhihao1@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9f19aab47ced012eddef1e2bc96007efc7713b61 ]
The LLVM template is first echo-ed into command_out and then
command_out executed. The echo surrounds the template with double
quotes, however, the template itself may contain quotes. This is
generally innocuous but in tools/perf/tests/bpf-script-test-prologue.c
we see:
...
SEC("func=null_lseek file->f_mode offset orig")
...
where the first double quote ends the double quote of the echo, then
the > redirects output into a file called f_mode.
To avoid this inadvertent behavior substitute redirects and similar
characters to be ASCII control codes, then substitute the output in
the echo back again.
Fixes: 5eab5a7ee032acaa ("perf llvm: Display eBPF compiling command in debug output")
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andrii Nakryiko <andrii@kernel.org>
Cc: bpf@vger.kernel.org
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: llvm@lists.linux.dev
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230105082609.344538-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 33309ecda0070506c49182530abe7728850ebe78 ]
The dcache_by_line_op macro suffers from a couple of small problems:
First, the GAS directives that are currently being used rely on
assembler behavior that is not documented, and probably not guaranteed
to produce the correct behavior going forward. As a result, we end up
with some undefined symbols in cache.o:
$ nm arch/arm64/mm/cache.o
...
U civac
...
U cvac
U cvap
U cvau
This is due to the fact that the comparisons used to select the
operation type in the dcache_by_line_op macro are comparing symbols
not strings, and even though it seems that GAS is doing the right
thing here (undefined symbols by the same name are equal to each
other), it seems unwise to rely on this.
Second, when patching in a DC CVAP instruction on CPUs that support it,
the fallback path consists of a DC CVAU instruction which may be
affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE.
Solve these issues by unrolling the various maintenance routines and
using the conditional directives that are documented as operating on
strings. To avoid the complexity of nested alternatives, we move the
DC CVAP patching to __clean_dcache_area_pop, falling back to a branch
to __clean_dcache_area_poc if DCPOP is not supported by the CPU.
Reported-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Change-Id: I006dd10a0f3706b9302832d04c65262861239709
… vector commit ed6ed11830a9ded520db31a6e2b69b6b0a1eb0e2 upstream. Replace the literal load of the addend vector with a sequence that performs each add individually. This sequence is only 2 instructions longer than the original, and 2% faster on Cortex-A53. This is an improvement by itself, but also works around a Clang issue, whose integrated assembler does not implement the GNU ARM asm syntax completely, and does not support the =literal notation for FP registers (more info at https://bugs.llvm.org/show_bug.cgi?id=38642) Cc: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Change-Id: Ic8f7adcd28bd2da57b465a8e11e9d55b5669a539
… code In order to be able to reuse the generic AES code as a fallback for situations where the NEON may not be used, update the key handling to match the byte order of the generic code: it stores round keys as sequences of 32-bit quantities rather than streams of bytes, and so our code needs to be updated to reflect that. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Change-Id: Ia5d6a7464a33240cafc544e79becd47018ecb703
commit 019cd46984d04703a39924178f503a98436ac0d7 upstream. Most crypto drivers involving kernel mode NEON take care to put the code that actually touches the NEON register file in a separate compilation unit, to prevent the compiler from reordering code that preserves or restores the NEON context with code that may corrupt it. This is necessary because we currently have no way to express the restrictions imposed upon use of the NEON in kernel mode in a way that the compiler understands. However, in the case of aes-ce-cipher, it did not seem unreasonable to deviate from this rule, given how it does not seem possible for the compiler to reorder cross object function calls with asm blocks whose in- and output constraints reflect that it reads from and writes to memory. Now that LTO is being proposed for the arm64 kernel, it is time to revisit this. The link time optimization may replace the function calls to kernel_neon_begin() and kernel_neon_end() with instantiations of the IR that make up its implementation, allowing further reordering with the asm block. So let's clean this up, and move the asm() blocks into a separate .S file. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-By: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Matthias Kaehlcke <mka@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [ bgcngm: Backported to 4.9 ] Signed-off-by: Bruno Martins <bgcngm@gmail.com> Change-Id: I7b271d83a3d5baf81aa5fca69cd4f2817945a477
This is needed because clang doesn't select which linker to use based on $LD but rather -fuse-ld=lld. This is problematic especially for cc-ldoption, which checks for linker flag support via invoking the compiler, rather than the linker. (am from https://lkml.org/lkml/2019/2/11/1947) Link: ClangBuiltLinux/linux#342 Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Bug: 63740206 Change-Id: I3edf2f0f6c0bac842bef22194bd48a993fc0e3c0 Signed-off-by: Yousef Algadri <yusufgadrie@gmail.com> Signed-off-by: Raphiel Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
With the recent syntax extension, Kconfig is now able to evaluate the compiler / toolchain capability. However, accumulating flags to 'LD' is not compatible with the way it works; 'LD' must be passed to Kconfig to call $(ld-option,...) from Kconfig files. If you tweak 'LD' in arch Makefile depending on CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency between Makefile and Kconfig. Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Change-Id: I8a7654684975d45e979917e3b1c4b6249dec02ec
…able Not all toolchains have the baremetal elf targets, RedHat/Fedora ones in particular. So, probe for whether it's available and use the previous (linux) targets if it isn't. Reported-by: Laura Abbott <labbott@redhat.com> Tested-by: Laura Abbott <labbott@redhat.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Paul Kocialkowski <contact@paulk.fr> Signed-off-by: Olof Johansson <olof@lixom.net> Signed-off-by: Will Deacon <will.deacon@arm.com> Change-Id: Icf5462a8318b347cf11559c1654886c48c7a62b5
For arm64: 0.34% size improvement with lld -O2 over lld for vmlinux. 3.3% size improvement with lld -O2 over lld for Image.lz4-dtb. (am from https://lkml.org/lkml/2019/2/11/1949) Change-Id: Ibdc7ecc9861562305b49456d6d37274ce8075e22 Link: ClangBuiltLinux/linux#343 Suggested-by: Rui Ueyama <ruiu@google.com> Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Bug: 63740206 Signed-off-by: Yousef Algadri <yusufgadrie@gmail.com> Signed-off-by: Raphiel Rollerscaperers <rapherion@raphielgang.org> Signed-off-by: Chenyang Zhong <zhongcy95@gmail.com>
The kernel needs to be compiled as a LP64 binary for ARM64, even when using a compiler that defaults to code-generation for the ILP32 ABI. Consequently, we need to explicitly pass '-mabi=lp64' (supported on gcc-4.9 and newer). Signed-off-by: Andrew Pinski <Andrew.Pinski@caviumnetworks.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Signed-off-by: Christoph Muellner <christoph.muellner@theobroma-systems.com> Signed-off-by: Yury Norov <ynorov@caviumnetworks.com> Reviewed-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Change-Id: Ife00e01e3e3a6d85841b88c2f1a042617bd61500
…4/lib/mem*.S commit ec9d78070de986ecf581ea204fd322af4d2477ec upstream. Commit 39d114d ("arm64: add KASAN support") added .weak directives to arch/arm64/lib/mem*.S instead of changing the existing SYM_FUNC_START_PI macros. This can lead to the assembly snippet `.weak memcpy ... .globl memcpy` which will produce a STB_WEAK memcpy with GNU as but STB_GLOBAL memcpy with LLVM's integrated assembler before LLVM 12. LLVM 12 (since https://reviews.llvm.org/D90108) will error on such an overridden symbol binding. Use the appropriate SYM_FUNC_START_WEAK_PI instead. Fixes: 39d114d ("arm64: add KASAN support") Reported-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Fangrui Song <maskray@google.com> Tested-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20201029181951.1866093-1-maskray@google.com Signed-off-by: Will Deacon <will@kernel.org> [nd: backport to adjust for missing: commit 3ac0f4526dfb ("arm64: lib: Use modern annotations for assembly functions") commit 35e61c77ef38 ("arm64: asm: Add new-style position independent function annotations")] Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Change-Id: Ibebbfa15f3337b5a2ac88ba683c5e429758d7a98
Bug: 145210207 Change-Id: I8f59ab53c94087d1e9ec0154337486ad8aad973f Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
On modules with no executable code, LLVM generates a __cfi_check stub, but won't align it to page size as expected. This change ensures the function is at the beginning of the .text section and correctly aligned for the CFI shadow. Bug: 148458318 Change-Id: I85ea31fa851bc23988f649b021b3ac7e9d9dcb38 Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
We use $(LD) to link vmlinux, modules, decompressors, etc. VDSO is the only exceptional case where $(CC) is used as the linker driver, but I do not know why we need to do so. VDSO uses a special linker script, and does not link standard libraries at all. I changed the Makefile to use $(LD) rather than $(CC). I tested this, and VDSO worked for me. Users will be able to use their favorite linker (e.g. lld instead of of bfd) by passing LD= from the command line. My plan is to rewrite all VDSO Makefiles to use $(LD), then delete cc-ldoption. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Change-Id: I8a14d6dd51d46b6942e68720e24217d1564b7869 [nd: conflicts due to ANDROID patches for LTO and SCS] (cherry picked from commit 691efbedc60d2a7364a90e38882fc762f06f52c4) Bug: 153418016 Bug: 157279372 Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: GhostMaster69-dev <rathore6375@gmail.com>
Commit 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to
link VDSO") switched to using LD explicitly. The --build-id option
needs to be passed explicitly, similar to x86. Add this option.
Fixes: 691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
[will: drop redundant use of 'call ld-option' as requested by Masahiro]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Change-Id: I4a0f5c1bb60bda682221a7ff96a783bf8731cc00
[nd: conflict due to ANDROID LTO and CFI]
(cherry picked from commit 7a0a93c51799edc45ee57c6cc1679aa94f1e03d5)
Bug: 153418016
Bug: 157279372
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: GhostMaster69-dev <rathore6375@gmail.com>
Here's a high level summary of the changes in this patch. For more information on rational, see the RFC. (https://discourse.llvm.org/t/rfc-a-unified-lto-bitcode-frontend/61774). - Add config parameter to LTO backend, specifying which LTO mode is desired when using unified LTO. - Add unified LTO flag to the summary index for efficiency. Unified LTO modules can be detected without parsing the module. - Make sure that the ModuleID is generated by incorporating more types of symbols. Differential Revision: https://reviews.llvm.org/D123803
Signed-off-by: Faiz Faadhillah <faiz.faadhillah@gmail.com>
Versions of gcc prior to gcc 5 emitted a __multi3 function call when dealing with TI types, resulting in failures when trying to link to libgcc, and more generally, bad performance. However, since gcc 5, the compiler supports actually emitting fast instructions, which means we can at long last enable this option and receive the speedups. The gcc commit that added proper Aarch64 support is: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d1ae7bb994f49316f6f63e6173f2931e837a351d This commit appears to be part of the gcc 5 release. There are still a few instructions, __ashlti3 and __ashrti3, which require libgcc, which is fine. Rather than linking to libgcc, we simply provide them ourselves, since they're not that complicated. Also enable for clang if used Change-Id: Iab816c6edc40dc5059e169ce2b1472f5078442fb Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: mydongistiny <jaysonedson@gmail.com> Signed-off-by: kdrag0n <dragon@khronodragon.com>
Commit fb8722735f50 ("arm64: support __int128 on gcc 5+") added support
for the __int128 data type, but this breaks the build in some configurations
where GCC ends up emitting calls to the __lshrti3 helper in libgcc, which
results in a link error:
kernel/sched/fair.o: In function `__calc_delta':
fair.c:(.text+0xca0): undefined reference to `__lshrti3'
kernel/time/timekeeping.o: In function `timekeeping_resume':
timekeeping.c:(.text+0x3f60): undefined reference to `__lshrti3'
make: *** [vmlinux] Error 1
Fix the build by providing an implementation of __lshrti3, like we do
already for __ashlti3 and __ashrti3.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: mydongistiny <jaysonedson@gmail.com>
Signed-off-by: kdrag0n <dragon@khronodragon.com>
This is entirely cosmetic, but somehow it was missed when sending differing versions of this patch. This just makes the file a bit more uniform. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> (cherry picked from commit f5ed22e2647cc89dd0a57936b38a582546527509) Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: kdrag0n <dragon@khronodragon.com>
Otherwise modules that use these arithmetic operations will fail to link. We accomplish this with the usual EXPORT_SYMBOL, which on most architectures goes in the .S file but the ARM64 maintainers prefer that insead it goes into arm64ksyms. While we're at it, we also fix this up to use SPDX, and I personally choose to relicense this as GPL2||BSD so that these symbols don't need to be export_symbol_gpl, so all modules can use the routines, since these are important general purpose compiler-generated function calls. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Reported-by: PaX Team <pageexec@freemail.hu> Cc: stable@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com> (cherry picked from commit 255845fc43a3aaf806852a1d3bc89bff1411ebe3) Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: kdrag0n <dragon@khronodragon.com>
* Ex when CUDA LLVM is pre-installed
./include/generated/compile.h:8:1: error: unknown type name 'Found'
8 | Found CUDA installation: /usr/local/cuda, version, LLD 18.0.1"
| ^
./include/generated/compile.h:8:11: error: expected ';' after top level declarator
8 | Found CUDA installation: /usr/local/cuda, version, LLD 18.0.1"
* When CUDA is installed the kernel version reflects that * add hot-cold-split optimization * add C/LD flags O2 * Remove duplicates * General changes
LLVM's integrated assembler appears to assume an argument with default
value is passed whenever it sees a comma right after the macro name.
It will be fine if the number of following arguments is one less than
the number of parameters specified in the macro definition. Otherwise,
it fails. For example, the following code works:
$ cat foo.s
.macro foo arg1=2, arg2=4
ldr r0, [r1, #\arg1]
ldr r0, [r1, #\arg2]
.endm
foo, arg2=8
$ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o
arm-linux-gnueabihf-objdump -dr ias.o
ias.o: file format elf32-littlearm
Disassembly of section .text:
00000000 <.text>:
0: e5910001 ldr r0, [r1, #2]
4: e5910003 ldr r0, [r1, #8]
While the the following code would fail:
$ cat foo.s
.macro foo arg1=2, arg2=4
ldr r0, [r1, #\arg1]
ldr r0, [r1, #\arg2]
.endm
foo, arg1=2, arg2=8
$ llvm-mc -triple=armv7a -filetype=obj foo.s -o ias.o
foo.s:6:14: error: too many positional arguments
foo, arg1=2, arg2=8
This causes build failures as follows:
arch/arm64/kernel/vdso/gettimeofday.S:230:24: error: too many positional
arguments
clock_gettime_return, shift=1
^
arch/arm64/kernel/vdso/gettimeofday.S:253:24: error: too many positional
arguments
clock_gettime_return, shift=1
^
arch/arm64/kernel/vdso/gettimeofday.S:274:24: error: too many positional
arguments
clock_gettime_return, shift=1
This error is not in mainline because commit 28b1a824a4f4 ("arm64: vdso:
Substitute gettimeofday() with C implementation") rewrote this assembler
file in C as part of a 25 patch series that is unsuitable for stable.
Just remove the comma in the clock_gettime_return invocations in 4.19 so
that GNU as and LLVM's integrated assembler work the same.
Link:
ClangBuiltLinux/linux#1349
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Jian Cai <jiancai@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: If006e175105cf7387be43fe1ed53d0563d10be54
commit 6f5459da2b8736720afdbd67c4bd2d1edba7d0e3 upstream.
Building an arm64 defconfig with clang's integrated assembler, this error
occurs:
<instantiation>:2:2: error: unrecognized instruction mnemonic
_ASM_EXTABLE 9999b, 9f
^
arch/arm64/mm/cache.S:50:1: note: while in macro instantiation
user_alt 9f, "dc cvau, x4", "dc civac, x4", 0
^
While GNU as seems fine with case-sensitive macro instantiations, clang
doesn't, so use the actual macro name (_asm_extable) as in the rest of
the file.
Also checked that the generated assembly matches the GCC output.
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Fixes: 290622e ("arm64: fix "dc cvau" cache operation on errata-affected core")
Link: ClangBuiltLinux/linux#924
Signed-off-by: Ilie Halip <ilie.halip@gmail.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:260:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
260 | void mali_exynos_coherency_reg_map()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:265:37: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
265 | void mali_exynos_coherency_reg_unmap()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:270:49: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
270 | void mali_exynos_coherency_set_coherency_feature()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:275:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
275 | void mali_exynos_llc_set_aruser()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/mali_exynos_kbase_entrypoint.c:280:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
280 | void mali_exynos_llc_set_awuser()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_platform.c:99:24: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
99 | void gpex_platform_term()
| ^
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:63:31: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
63 | int gpexbe_clock_get_boot_freq()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:68:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
68 | int gpexbe_clock_get_max_freq()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:92:26: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
92 | int gpexbe_clock_get_rate()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:97:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
97 | int gpexbe_clock_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.c:114:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
114 | void gpexbe_clock_term()
| ^
| void
5 errors generated.
make[4]: *** [scripts/Makefile.build:334: drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_clock.o] Error 1
make[4]: *** Waiting for unfinished jobs....
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:40:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
40 | int gpex_clock_get_boot_clock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:44:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
44 | int gpex_clock_get_max_clock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:48:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
48 | int gpex_clock_get_max_clock_limit()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:52:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
52 | int gpex_clock_get_min_clock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:56:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
56 | int gpex_clock_get_cur_clock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:60:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
60 | int gpex_clock_get_max_lock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:64:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
64 | int gpex_clock_get_min_lock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:334:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
334 | void gpex_clock_term()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:355:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
355 | int gpex_clock_get_clock_slow()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:407:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
407 | int gpex_clock_prepare_runtime_off()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:561:27: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
561 | void gpex_clock_mutex_lock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:566:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
566 | void gpex_clock_mutex_unlock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:334:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
334 | void gpex_clock_term()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_clock.c:355:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
355 | int gpex_clock_get_clock_slow()
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpu_dvfs_governor.c:34:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
34 | int gpex_dvfs_set_clock_callback()
CC drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs_external.o
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:175:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
175 | void gpex_dvfs_start()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:180:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
180 | void gpex_dvfs_stop()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:223:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
223 | int gpex_dvfs_enable()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:228:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
228 | int gpex_dvfs_disable()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:233:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
233 | static int gpu_dvfs_handler_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:246:35: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
246 | static int gpu_dvfs_handler_deinit()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:298:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
298 | void gpex_dvfs_term()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_dvfs.c:306:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
306 | int gpex_dvfs_get_status()
drivers/gpu/arm/bv_r38p1/../exynos/backend/dummy/gpexbe_secure_dummy.c:28:64: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
28 | struct protected_mode_ops *gpexbe_secure_get_protected_mode_ops()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:44:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
44 | int gpexbe_smc_protection_enable()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:71:34: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
71 | int gpexbe_smc_protection_disable()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:117:32: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
117 | void gpexbe_smc_notify_power_on()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:120:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
120 | void gpexbe_smc_notify_power_off()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_smc.c:44:33: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
44 | int gpexbe_smc_protection_enable()
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_qos.c:121:18: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
121 | int gpex_qos_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_qos.c:182:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
182 | void gpex_qos_term()
|
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos.c:3:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
3 | int gpexbe_qos_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos.c:8:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
8 | void gpexbe_qos_term()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_bts_v1.c:33:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
33 | int gpexbe_bts_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_bts_v1.c:38:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
38 | void gpexbe_bts_term()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_debug_v1.c:39:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
39 | int gpexbe_debug_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_debug_v1.c:44:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
44 | void gpexbe_debug_term()
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:40:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
40 | int gpex_thermal_gpu_normal()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:161:22: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
161 | int gpex_thermal_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_thermal.c:170:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
170 | void gpex_thermal_term()
| ^
| void
3 errors generated.
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_notifier.c:109:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
109 | int gpexbe_notifier_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_notifier.c:126:26: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
126 | void gpexbe_notifier_term()
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:68:25: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
68 | int gpexbe_pm_get_status()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:79:56: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
79 | struct exynos_pm_domain *gpexbe_pm_get_exynos_pm_domain()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:84:27: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
84 | void gpexbe_pm_access_lock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:90:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
90 | void gpexbe_pm_access_unlock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:133:28: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
133 | int gpexbe_pm_pd_control_up()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:138:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
138 | int gpexbe_pm_pd_control_down()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:143:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
143 | int gpexbe_pm_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_pm.c:159:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
159 | void gpexbe_pm_term()
drivers/gpu/arm/bv_r38p1/../exynos/tests/runtime_test_runner_dummy.c:23:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
23 | int runtime_test_runner_init()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/tests/runtime_test_runner_dummy.c:28:30: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
28 | void runtime_test_runner_term()
| ^
| void
2 errors generated.
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:104:29: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
104 | int gpex_pm_get_power_status()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:109:18: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
109 | void gpex_pm_lock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/frontend/gpex_pm.c:114:20: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
114 | void gpex_pm_unlock()
| ^
| void
drivers/gpu/arm/bv_r38p1/../exynos/workarounds/gpexwa_ehmp.c:54:23: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
54 | void gpexwa_ehmp_unset() {
drivers/gpu/arm/bv_r38p1/../exynos/backend/gpexbe_qos_internal.h:21:15: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] 21 | static inline pmqos_flag_check(mali_pmqos_flags type, mali_pmqos_flags in)
drivers/net/wireless/bcmdhd_101_16/dhd_linux.c:19280:21: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 19280 | dhd_get_time_str_len() drivers/net/wireless/bcmdhd_101_16//wl_cfg_btcoex.c:437:37: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] void wl_cfg80211_btcoex_kill_handler() drivers/net/wireless/bcmdhd_101_16//wl_cfg_btcoex.c:450:31: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] void wl_cfg80211_btcoex_deinit() drivers/net/wireless/bcmdhd_101_16/dhd_linux_platdev.c:867:34: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes] 867 | static int dhd_wifi_platform_load()
drivers/soc/samsung/exynos-hdcp/exynos-hdcp2-teeif.c:58:19: error: a function declaration without a prototype is deprecated in all versions of C [-Werror,-Wstrict-prototypes]
58 | int hdcp_tee_close()
| ^
| void
* Android 13 Driver * EARLY_SUSPEND * Also fix compilation errors (void)
commit 1e1b6d63d6340764e00356873e5794225a2a03ea upstream.
LLVM implemented a recent "libcall optimization" that lowers calls to
`sprintf(dest, "%s", str)` where the return value is used to
`stpcpy(dest, str) - dest`.
This generally avoids the machinery involved in parsing format strings.
`stpcpy` is just like `strcpy` except it returns the pointer to the new
tail of `dest`. This optimization was introduced into clang-12.
Implement this so that we don't observe linkage failures due to missing
symbol definitions for `stpcpy`.
Similar to last year's fire drill with: commit 5f074f3e192f
("lib/string.c: implement a basic bcmp")
The kernel is somewhere between a "freestanding" environment (no full
libc) and "hosted" environment (many symbols from libc exist with the
same type, function signature, and semantics).
As Peter Anvin notes, there's not really a great way to inform the
compiler that you're targeting a freestanding environment but would like
to opt-in to some libcall optimizations (see pr/47280 below), rather
than opt-out.
Arvind notes, -fno-builtin-* behaves slightly differently between GCC
and Clang, and Clang is missing many __builtin_* definitions, which I
consider a bug in Clang and am working on fixing.
Masahiro summarizes the subtle distinction between compilers justly:
To prevent transformation from foo() into bar(), there are two ways in
Clang to do that; -fno-builtin-foo, and -fno-builtin-bar. There is
only one in GCC; -fno-buitin-foo.
(Any difference in that behavior in Clang is likely a bug from a missing
__builtin_* definition.)
Masahiro also notes:
We want to disable optimization from foo() to bar(),
but we may still benefit from the optimization from
foo() into something else. If GCC implements the same transform, we
would run into a problem because it is not -fno-builtin-bar, but
-fno-builtin-foo that disables that optimization.
In this regard, -fno-builtin-foo would be more future-proof than
-fno-built-bar, but -fno-builtin-foo is still potentially overkill. We
may want to prevent calls from foo() being optimized into calls to
bar(), but we still may want other optimization on calls to foo().
It seems that compilers today don't quite provide the fine grain control
over which libcall optimizations pseudo-freestanding environments would
prefer.
Finally, Kees notes that this interface is unsafe, so we should not
encourage its use. As such, I've removed the declaration from any
header, but it still needs to be exported to avoid linkage errors in
modules.
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Suggested-by: Andy Lavr <andy.lavr@gmail.com>
Suggested-by: Arvind Sankar <nivedita@alum.mit.edu>
Suggested-by: Joe Perches <joe@perches.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20200914161643.938408-1-ndesaulniers@google.com
Link: https://bugs.llvm.org/show_bug.cgi?id=47162
Link: https://bugs.llvm.org/show_bug.cgi?id=47280
Link: ClangBuiltLinux/linux#1126
Link: https://man7.org/linux/man-pages/man3/stpcpy.3.html
Link: https://pubs.opengroup.org/onlinepubs/9699919799/functions/stpcpy.html
Link: https://reviews.llvm.org/D85963
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
duhansysl
added a commit
that referenced
this pull request
Sep 30, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.