default toolchain #218
Open
default toolchain #218
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
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
…char * Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
… check Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
…ress clang warning Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
…suppress the warning Signed-off-by: Denis Efremov <efremov@linux.com>
…sscanf format Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
…e() result Signed-off-by: Denis Efremov <efremov@linux.com>
…ation warning Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
…ections for module build Modules do not tend to cope with -ffunction-sections, even though they do not link with -gc-sections. It may be possible for unused symbols to be trimmed from modules, but in general that would take much more work in architecture module linker scripts. For now, enable these only for kernel build. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Architectures that are capable can select HAVE_LD_DEAD_CODE_DATA_ELIMINATION to enable selection of that option (as an EXPERT kernel option). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Since commit 5d20ee3192a5 ("kbuild: Allow LD_DEAD_CODE_DATA_ELIMINATION
to be selectable if enabled"), HAVE_LD_DEAD_CODE_DATA_ELIMINATION is
supposed to be selected by architectures that are capable of this
functionality. LD_DEAD_CODE_DATA_ELIMINATION is now users' selection.
Update the help message.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
KEEP more tables, and add the function/data section wildcard to more section selections. This is a little ad-hoc at the moment, but kernel code should be moved to consistently use .text..x (note: double dots) for explicit sections and all references to it in the linker script can be made with TEXT_MAIN, and similarly for other sections. For now, let's see if major architectures move to enabling this option then we can do some refactoring passes. Otherwise if it remains unused or superseded by LTO, this may not be required. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Enabling both CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y and CONFIG_GCOV_PROFILE_ALL=y results in linker warnings: warning: orphan section `.data..LPBX1' being placed in section `.data..LPBX1'. LD_DEAD_CODE_DATA_ELIMINATION adds compiler flag -fdata-sections. This option causes GCC to create separate data sections for data objects, including those generated by GCC internally for gcov profiling. The names of these objects start with a dot (.LPBX0, .LPBX1), resulting in section names starting with 'data..'. As section names starting with 'data..' are used for specific purposes in the Linux kernel, the linker script does not automatically include them in the output data section, resulting in the "orphan section" linker warnings. Fix this by specifically including sections named "data..LPBX*" in the data section. Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au> Tested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
A recent LLVM 11 commit [1] made LLD stop implicitly coalescing some
temporary LLVM sections, namely .{data,bss}..compoundliteral.XXX:
[30] .data..compoundli PROGBITS ffffffff9ac9a000 19e9a000
000000000000cea0 0000000000000000 WA 0 0 32
[31] .rela.data..compo RELA 0000000000000000 40965440
0000000000001d88 0000000000000018 I 2238 30 8
[32] .data..compoundli PROGBITS ffffffff9aca6ea0 19ea6ea0
00000000000033c0 0000000000000000 WA 0 0 32
[33] .rela.data..compo RELA 0000000000000000 409671c8
0000000000000948 0000000000000018 I 2238 32 8
[...]
[2213] .bss..compoundlit NOBITS ffffffffa3000000 1d85c000
00000000000000a0 0000000000000000 WA 0 0 32
[2214] .bss..compoundlit NOBITS ffffffffa30000a0 1d85c000
0000000000000040 0000000000000000 WA 0 0 32
[...]
.{data,bss}..L<symbol name> sections are also created in some cases.
While there aren't any in this example, they should also be coalesced to
be safe in case some config or future LLVM change makes it start
creating more of those sections in the future. For example, enabling
global merging causes ..L_MergedGlobals sections to be created, but it's
likely that other changes will result in such sections as well.
While these extra sections don't typically cause any breakage, they do
inflate the vmlinux size due to the overhead of storing metadata for
thousands of extra sections.
It's also worth noting that for some reason, some downstream Android
kernels can't boot at all if these sections aren't coalesced.
This issue isn't limited to any specific architecture; it affects arm64
and x86 if CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is forced on.
Example on x86 allyesconfig:
Before: 2241 sections, 1171169 KiB
After: 56 sections, 1170972 KiB
[1] llvm/llvm-project@9e33c09
Suggested-by: Fangrui Song <maskray@google.com>
Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: stable@vger.kernel.org # v4.4+
Link: ClangBuiltLinux/linux#958
cuttlefish_defconfig explicitly enables options that fail to compile with compilers other than clang. This change detects when a different compiler is used and disables clang-specific features after printing a warning. Bug: 145297810 Change-Id: I3371576b45c9715a63c5668ab58e996cab612f53 Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This adds support for compiling the kernel with optimizations offered by LLVM's polyhedral loop optimizer known as Polly, which can improve performance by improving cache locality in loops. Note that LLVM is not compiled with Polly by default -- it must be enabled explicitly. Signed-off-by: Danny Lin <danny@kdrag0n.dev>
Signed-off-by: Denis Efremov <efremov@linux.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> (cherry picked from commit 64ea9b4b072b37bd624dd98b963161fd22c1be34)
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>
(cherry picked from commit a9ee8bba814d956404c12b1c2e2c24cf4b710f08)
ld.lld distributed in clang-r353983c AOSP LLVM release (the final AOSP LLVM release for Android Q) did not support `-n` linker flag. It was eventually added to clang-r360593. Android OEM's may wish to still use ld.lld to link their kernels for Q. This flag was disabled for Pixel 4 in go/pag/1258086. This patch is equivalent, but rebased on upstream changes that removed cc-ldoption in favor of ld-option. For Android R, the final AOSP LLVM release, clang-r383902 has long supported `-n` for ld.lld. Change-Id: Iab41c9e1039e163113b428fc487a4a0708822faa Bug: 63740206 Bug: 157279372 Link: ClangBuiltLinux/linux#340 Link: https://bugs.llvm.org/show_bug.cgi?id=40542 Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Change VM_MAX_READAHEAD value from the default 128KB to a configurable value. This will allow the readahead window to grow to a maximum size bigger than 128KB during boot, which could benefit to sequential read throughput and thus boot performance. Signed-off-by: Wei Wang <wvw@google.com>
With CONFIG_THINLTO and CFI both enabled, LLVM appends a hash to the names of all static functions. This breaks userspace tools, so strip out the hash from output. Bug: 147422318 Change-Id: Ibea6be089d530e92dcd191481cb02549041203f6 Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
A trace point string cannot be const because the underlying special section is not marked const. An LTO build complains about the section attribute mismatch. Fix it by not marking the trace point string in afs const. Cc: dhowells@redhat.com Signed-off-by: Andi Kleen <ak@linux.intel.com>
…disabled Otherwise LTO will inline them anyways and cause a large kernel text increase. Since the explicit intention here is to not inline them marking them noinline is good documentation even for the non LTO case. Signed-off-by: Andi Kleen <ak@linux.intel.com>
The single caller passes a string to delta_ipc_open, which copies with a
fixed size larger than the string. So it copies some random data after
the original string the ro segment.
If the string was at the end of a page it may fault.
Just copy the string with a normal strcpy after clearing the field.
Found by a LTO build (which errors out)
because the compiler inlines the functions and can resolve
the string sizes and triggers the compile time checks in memcpy.
In function ‘memcpy’,
inlined from ‘delta_ipc_open.constprop’ at linux/drivers/media/platform/sti/delta/delta-ipc.c:178:0,
inlined from ‘delta_mjpeg_ipc_open’ at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:227:0,
inlined from ‘delta_mjpeg_decode’ at linux/drivers/media/platform/sti/delta/delta-mjpeg-dec.c:403:0:
/home/andi/lsrc/linux/include/linux/string.h:337:0: error: call to ‘__read_overflow2’ declared with attribute error: detected read beyond size of object passed as 2nd parameter
__read_overflow2();
Cc: hugues.fruchet@st.com
Cc: mchehab@s-opensource.com
Signed-off-by: Andi Kleen <ak@linux.intel.com>
gcc 5 has a new no_reorder attribute that prevents top level reordering only for that symbol. Kernels don't like any reordering of initcalls between files, as several initcalls depend on each other. LTO previously needed to use -fno-toplevel-reordering to prevent boot failures. Add a __noreorder wrapper for the no_reorder attribute and use it for initcalls. Signed-off-by: Andi Kleen <ak@linux.intel.com>
Disable LTO for the BPF interpreter. This works around a gcc bug in the LTO partitioner that partitions the jumptable used the BPF interpreter into a different LTO unit. This in term causes assembler errors because the jump table contains references to the code labels in the original file. gcc problem tracked in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 Signed-off-by: Andi Kleen <ak@linux.intel.com>
Building the kernel with an LTO-enabled GCC spits out the following "const"
warning for the cpu_ops code:
mm/percpu.c:2168:20: error: pcpu_fc_names causes a section type conflict
with dt_supported_cpu_ops
const char * const pcpu_fc_names[PCPU_FC_NR] __initconst = {
^
arch/arm64/kernel/cpu_ops.c:34:37: note: ‘dt_supported_cpu_ops’ was declared here
static const struct cpu_operations *dt_supported_cpu_ops[] __initconst = {
Fix it by adding missed const qualifiers.
Signed-off-by: Yury Norov <ynorov@caviumnetworks.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Based on Andi Kleen <ak@linux.intel.com> work. Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
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.