7192ad2a | 28-Nov-2023 |
Nathan Chancellor <nathan@kernel.org> |
arm64: vdso32: Define BUILD_VDSO32_64 to correct prototypes
After commit 42874e4eb35b ("arch: vdso: consolidate gettime prototypes"), there are a couple of errors when building the 32-bit compat vDS
arm64: vdso32: Define BUILD_VDSO32_64 to correct prototypes
After commit 42874e4eb35b ("arch: vdso: consolidate gettime prototypes"), there are a couple of errors when building the 32-bit compat vDSO for arm64:
arch/arm64/kernel/vdso32/vgettimeofday.c:10:5: error: conflicting types for '__vdso_clock_gettime'; have 'int(clockid_t, struct old_timespec32 *)' {aka 'int(int, struct old_timespec32 *)'} 10 | int __vdso_clock_gettime(clockid_t clock, | ^~~~~~~~~~~~~~~~~~~~ In file included from arch/arm64/kernel/vdso32/vgettimeofday.c:8: include/vdso/gettime.h:16:5: note: previous declaration of '__vdso_clock_gettime' with type 'int(clockid_t, struct __kernel_timespec *)' {aka 'int(int, struct __kernel_timespec *)'} 16 | int __vdso_clock_gettime(clockid_t clock, struct __kernel_timespec *ts); | ^~~~~~~~~~~~~~~~~~~~ arch/arm64/kernel/vdso32/vgettimeofday.c:28:5: error: conflicting types for '__vdso_clock_getres'; have 'int(clockid_t, struct old_timespec32 *)' {aka 'int(int, struct old_timespec32 *)'} 28 | int __vdso_clock_getres(clockid_t clock_id, | ^~~~~~~~~~~~~~~~~~~ include/vdso/gettime.h:15:5: note: previous declaration of '__vdso_clock_getres' with type 'int(clockid_t, struct __kernel_timespec *)' {aka 'int(int, struct __kernel_timespec *)'} 15 | int __vdso_clock_getres(clockid_t clock, struct __kernel_timespec *res); | ^~~~~~~~~~~~~~~~~~~
The type of the second parameter in __vdso_clock_getres() and __vdso_clock_gettime() changes based on whether compiling for 32-bit vs. 64-bit, which is controlled by CONFIG_64BIT or the preprocessor macro BUILD_VDSO32_64, which denotes a 32-bit vDSO is being built for a 64-bit architecture. Since this situation is the latter case, define BUILD_VDSO32_64 before the inclusion of include/vdso/gettime.h to clear up the warning
Fixes: 42874e4eb35b ("arch: vdso: consolidate gettime prototypes") Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org> Closes: https://lore.kernel.org/CA+G9fYtV6X=c3JVTTAX89_=wc+uqLpzggnsbGSx-98m_5yd5yw@mail.gmail.com/ Reported-by: Mark Brown <broonie@kernel.org> Closes: https://lore.kernel.org/ZWCRWArzbTYUjvon@finisterre.sirena.org.uk/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
9e07352e | 30-Jun-2022 |
Nathan Chancellor <nathan@kernel.org> |
arm64: vdso32: Add DWARF_DEBUG
When building the 32-bit vDSO with LLVM 15 and CONFIG_DEBUG_INFO, there are the following orphan section warnings:
ld.lld: warning: arch/arm64/kernel/vdso32/note.o:
arm64: vdso32: Add DWARF_DEBUG
When building the 32-bit vDSO with LLVM 15 and CONFIG_DEBUG_INFO, there are the following orphan section warnings:
ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_abbrev) is being placed in '.debug_abbrev' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_info) is being placed in '.debug_info' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_str_offsets) is being placed in '.debug_str_offsets' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_str) is being placed in '.debug_str' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_addr) is being placed in '.debug_addr' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_line) is being placed in '.debug_line' ld.lld: warning: arch/arm64/kernel/vdso32/note.o:(.debug_line_str) is being placed in '.debug_line_str' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_loclists) is being placed in '.debug_loclists' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_abbrev) is being placed in '.debug_abbrev' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_info) is being placed in '.debug_info' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_rnglists) is being placed in '.debug_rnglists' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_str_offsets) is being placed in '.debug_str_offsets' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_str) is being placed in '.debug_str' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_addr) is being placed in '.debug_addr' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_frame) is being placed in '.debug_frame' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_line) is being placed in '.debug_line' ld.lld: warning: arch/arm64/kernel/vdso32/vgettimeofday.o:(.debug_line_str) is being placed in '.debug_line_str'
These are DWARF5 sections, as that is the implicit default version for clang-14 and newer when just '-g' is used. All DWARF sections are handled by the DWARF_DEBUG macro from include/asm-generic/vmlinux.lds.h so use that macro here to fix the warnings regardless of DWARF version.
Fixes: 9d4775b332e1 ("arm64: vdso32: enable orphan handling for VDSO") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20220630153121.1317045-3-nathan@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
859716b4 | 30-Jun-2022 |
Nathan Chancellor <nathan@kernel.org> |
arm64: vdso32: Shuffle .ARM.exidx section above ELF_DETAILS
When building the 32-bit vDSO after commit 5c4fb60816ea ("arm64: vdso32: add ARM.exidx* sections"), ld.lld 11 fails to link:
ld.lld: er
arm64: vdso32: Shuffle .ARM.exidx section above ELF_DETAILS
When building the 32-bit vDSO after commit 5c4fb60816ea ("arm64: vdso32: add ARM.exidx* sections"), ld.lld 11 fails to link:
ld.lld: error: could not allocate headers ld.lld: error: unable to place section .text at file offset [0x2A0, 0xBB1]; check your linker script for overflows ld.lld: error: unable to place section .comment at file offset [0xBB2, 0xC8A]; check your linker script for overflows ld.lld: error: unable to place section .symtab at file offset [0xC8C, 0xE0B]; check your linker script for overflows ld.lld: error: unable to place section .strtab at file offset [0xE0C, 0xF1C]; check your linker script for overflows ld.lld: error: unable to place section .shstrtab at file offset [0xF1D, 0xFAA]; check your linker script for overflows ld.lld: error: section .ARM.exidx file range overlaps with .hash >>> .ARM.exidx range is [0x90, 0xCF] >>> .hash range is [0xB4, 0xE3]
ld.lld: error: section .hash file range overlaps with .ARM.attributes >>> .hash range is [0xB4, 0xE3] >>> .ARM.attributes range is [0xD0, 0x10B]
ld.lld: error: section .ARM.attributes file range overlaps with .dynsym >>> .ARM.attributes range is [0xD0, 0x10B] >>> .dynsym range is [0xE4, 0x133]
ld.lld: error: section .ARM.exidx virtual address range overlaps with .hash >>> .ARM.exidx range is [0x90, 0xCF] >>> .hash range is [0xB4, 0xE3]
ld.lld: error: section .ARM.exidx load address range overlaps with .hash >>> .ARM.exidx range is [0x90, 0xCF] >>> .hash range is [0xB4, 0xE3]
This was fixed in ld.lld 12 with a change to match GNU ld's semantics of placing non-SHF_ALLOC sections after SHF_ALLOC sections.
To workaround this issue, move the .ARM.exidx section before the .comment, .symtab, .strtab, and .shstrtab sections (ELF_DETAILS) so that those sections remain contiguous with the .ARM.attributes section.
Fixes: 5c4fb60816ea ("arm64: vdso32: add ARM.exidx* sections") Link: https://github.com/llvm/llvm-project/commit/ec29538af2e0886a65f479d6a533956a1c478132 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20220630153121.1317045-2-nathan@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
4274929c | 28-Jun-2022 |
Joey Gouly <joey.gouly@arm.com> |
arm64: vdso*: place got/plt sections in .rodata
The vDSO will not contain absolute relocations, so place these sections in .rodata.
Signed-off-by: Joey Gouly <joey.gouly@arm.com> Link: https://lore
arm64: vdso*: place got/plt sections in .rodata
The vDSO will not contain absolute relocations, so place these sections in .rodata.
Signed-off-by: Joey Gouly <joey.gouly@arm.com> Link: https://lore.kernel.org/linux-arm-kernel/00abb0c5-6360-0004-353f-e7a88b3bd22c@arm.com/ Cc: Will Deacon <will@kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/r/20220628151307.35561-3-joey.gouly@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
5c4fb608 | 28-Jun-2022 |
Joey Gouly <joey.gouly@arm.com> |
arm64: vdso32: add ARM.exidx* sections
These show up when building with clang+lld.
Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Vincenzo Frascino <vincenzo.f
arm64: vdso32: add ARM.exidx* sections
These show up when building with clang+lld.
Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/r/20220628151307.35561-2-joey.gouly@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
9d4775b3 | 10-May-2022 |
Joey Gouly <joey.gouly@arm.com> |
arm64: vdso32: enable orphan handling for VDSO
Like vmlinux, enable orphan-handling for the compat VDSO32. This can catch subtle errors that might arise from unexpected sections being included.
Sig
arm64: vdso32: enable orphan handling for VDSO
Like vmlinux, enable orphan-handling for the compat VDSO32. This can catch subtle errors that might arise from unexpected sections being included.
Signed-off-by: Joey Gouly <joey.gouly@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Kees Cook <keescook@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/r/20220510095834.32394-5-joey.gouly@arm.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
e8c07082 | 08-Mar-2022 |
Arnd Bergmann <arnd@arndb.de> |
Kbuild: move to -std=gnu11
During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() lo
Kbuild: move to -std=gnu11
During a patch discussion, Linus brought up the option of changing the C standard version from gnu89 to gnu99, which allows using variable declaration inside of a for() loop. While the C99, C11 and later standards introduce many other features, most of these are already available in gnu89 as GNU extensions as well.
An earlier attempt to do this when gcc-5 started defaulting to -std=gnu11 failed because at the time that caused warnings about designated initializers with older compilers. Now that gcc-5.1 is the minimum compiler version used for building kernels, that is no longer a concern. Similarly, the behavior of 'inline' functions changes between gnu89 using gnu_inline behavior and gnu11 using standard c99+ behavior, but this was taken care of by defining 'inline' to include __attribute__((gnu_inline)) in order to allow building with clang a while ago.
Nathan Chancellor reported a new -Wdeclaration-after-statement warning that appears in a system header on arm, this still needs a workaround.
The differences between gnu99, gnu11, gnu1x and gnu17 are fairly minimal and mainly impact warnings at the -Wpedantic level that the kernel never enables. Between these, gnu11 is the newest version that is supported by all supported compiler versions, though it is only the default on gcc-5, while all other supported versions of gcc or clang default to gnu1x/gnu17.
Link: https://lore.kernel.org/lkml/CAHk-=wiyCH7xeHcmiFJ-YgXUy2Jaj7pnkdKpcovt8fYbVFW3TA@mail.gmail.com/ Link: https://github.com/ClangBuiltLinux/linux/issues/1603 Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Marco Elver <elver@google.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: David Sterba <dsterba@suse.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Alex Shi <alexs@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
3e6f8d1f | 20-Oct-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
arm64: vdso32: require CROSS_COMPILE_COMPAT for gcc+bfd
Similar to commit 231ad7f409f1 ("Makefile: infer --target from ARCH for CC=clang") There really is no point in setting --target based on $CROS
arm64: vdso32: require CROSS_COMPILE_COMPAT for gcc+bfd
Similar to commit 231ad7f409f1 ("Makefile: infer --target from ARCH for CC=clang") There really is no point in setting --target based on $CROSS_COMPILE_COMPAT for clang when the integrated assembler is being used, since commit ef94340583ee ("arm64: vdso32: drop -no-integrated-as flag").
Allows COMPAT_VDSO to be selected without setting $CROSS_COMPILE_COMPAT when using clang and lld together.
Before: $ ARCH=arm64 CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make -j72 LLVM=1 defconfig $ grep CONFIG_COMPAT_VDSO .config CONFIG_COMPAT_VDSO=y $ ARCH=arm64 make -j72 LLVM=1 defconfig $ grep CONFIG_COMPAT_VDSO .config $
After: $ ARCH=arm64 CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make -j72 LLVM=1 defconfig $ grep CONFIG_COMPAT_VDSO .config CONFIG_COMPAT_VDSO=y $ ARCH=arm64 make -j72 LLVM=1 defconfig $ grep CONFIG_COMPAT_VDSO .config CONFIG_COMPAT_VDSO=y
Reviewed-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Link: https://lore.kernel.org/r/20211019223646.1146945-5-ndesaulniers@google.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
14831fad | 20-Oct-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
arm64: vdso32: suppress error message for 'make mrproper'
When running the following command without arm-linux-gnueabi-gcc in one's $PATH, the following warning is observed:
$ ARCH=arm64 CROSS_COMP
arm64: vdso32: suppress error message for 'make mrproper'
When running the following command without arm-linux-gnueabi-gcc in one's $PATH, the following warning is observed:
$ ARCH=arm64 CROSS_COMPILE_COMPAT=arm-linux-gnueabi- make -j72 LLVM=1 mrproper make[1]: arm-linux-gnueabi-gcc: No such file or directory
This is because KCONFIG is not run for mrproper, so CONFIG_CC_IS_CLANG is not set, and we end up eagerly evaluating various variables that try to invoke CC_COMPAT.
This is a similar problem to what was observed in commit dc960bfeedb0 ("h8300: suppress error messages for 'make clean'")
Reported-by: Lucas Henneman <henneman@google.com> Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211019223646.1146945-4-ndesaulniers@google.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|
a517faa9 | 20-Oct-2021 |
Nick Desaulniers <ndesaulniers@google.com> |
arm64: vdso32: drop test for -march=armv8-a
As Arnd points out: gcc-4.8 already supported -march=armv8, and we require gcc-5.1 now, so both this #if/#else construct and the corresponding "cc32
arm64: vdso32: drop test for -march=armv8-a
As Arnd points out: gcc-4.8 already supported -march=armv8, and we require gcc-5.1 now, so both this #if/#else construct and the corresponding "cc32-option,-march=armv8-a" check should be obsolete now.
Link: https://lore.kernel.org/lkml/CAK8P3a3UBEJ0Py2ycz=rHfgog8g3mCOeQOwO0Gmp-iz6Uxkapg@mail.gmail.com/ Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211019223646.1146945-3-ndesaulniers@google.com Signed-off-by: Will Deacon <will@kernel.org>
show more ...
|