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 <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…char * Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
… check Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…ress clang warning Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…suppress the warning Signed-off-by: Denis Efremov <[email protected]>
…sscanf format Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…e() result Signed-off-by: Denis Efremov <[email protected]>
…ation warning Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
…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 <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
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 <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
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 <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
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 <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
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 <[email protected]> Tested-by: Stephen Rothwell <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Signed-off-by: Peter Oberparleiter <[email protected]> Signed-off-by: Stephen Rothwell <[email protected]>
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 <[email protected]>
Signed-off-by: Danny Lin <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Cc: [email protected] # 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
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 <[email protected]> Signed-off-by: Will Deacon <[email protected]> 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 <[email protected]> (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 <[email protected]>
Signed-off-by: Laura Abbott <[email protected]>
[will: drop redundant use of 'call ld-option' as requested by Masahiro]
Signed-off-by: Will Deacon <[email protected]>
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 <[email protected]>
(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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
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: [email protected] Signed-off-by: Andi Kleen <[email protected]>
…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 <[email protected]>
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: [email protected]
Cc: [email protected]
Signed-off-by: Andi Kleen <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]>
Reviewed-by: Nick Desaulniers <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Based on Andi Kleen <[email protected]> work. Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
Signed-off-by: Denis Efremov <[email protected]>
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.