buildroot/package/binutils/Config.in.host

51 lines
1.2 KiB
Plaintext
Raw Normal View History

2004-10-08 23:33:05 -06:00
comment "Binutils Options"
toolchain: disable SSP support if CFI support in binutils is missing As reported by [1], SSP support is missing in the Buildroot toolchain for microblaze even if it's requested by selecting BR2_TOOLCHAIN_HAS_SSP config option. In Buildroot, we are using libssp provided by the C library (glibc, musl, uClibc-ng) when available. We are not using libssp from gcc. So for a microblaze glibc based toolchain, the SSP support is enabled unconditionally by a select BR2_TOOLCHAIN_HAS_SSP. BR2_microblazeel=y BR2_TOOLCHAIN_BUILDROOT_GLIBC=y BR2_KERNEL_HEADERS_4_14=y BR2_BINUTILS_VERSION_2_30_X=y BR2_GCC_VERSION_8_X=y BR2_TOOLCHAIN_BUILDROOT_CXX=y While building the toolchain, we are building host-binutils which provide "as" (assembler) and host-gcc-initial wich provide a minimal cross gcc (C only cross-compiler without any C library). When SSP support is requested, gcc_cv_libc_provides_ssp=yes is added to the make command line (see [2] for full details) With this setting, the SSP support is requested but it's not available in the end and the toochain build succeed. When the microblaze toolchain is imported to Biuldroot (2018.05) as external toolchain with BR2_TOOLCHAIN_EXTERNAL_HAS_SSP set, the build stop with : "SSP support not available in this toolchain, please disable BR2_TOOLCHAIN_EXTERNAL_HAS_SSP" The test is doing the following command line: echo 'void main(){}' | [...]/host/bin/microblazeel-linux-gcc.br_real -Werror -fstack-protector -x c - -o [...]/build/.br-toolchain-test.tmp cc1: error: -fstack-protector not supported for this target [-Werror] When we look at the gcc-final log file (config.log) we can see this error several time when using the minimal gcc (from host-gcc-initial). So Why the minimal gcc doesn't support SSP? When we look at the gcc-initial log file (config.log) we can see an error with 'as': configure:23194: checking assembler for cfi directives configure:23209: [...]microblazeel-buildroot-linux-gnu/bin/as -o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:2: Error: CFI is not supported for this target conftest.s:3: Error: CFI is not supported for this target conftest.s:4: Error: CFI is not supported for this target conftest.s:5: Error: CFI is not supported for this target conftest.s:6: Error: CFI is not supported for this target conftest.s:7: Error: CFI is not supported for this target configure:23212: $? = 1 configure: failed program was .text .cfi_startproc .cfi_offset 0, 0 .cfi_same_value 1 .cfi_def_cfa 1, 2 .cfi_escape 1, 2, 3, 4, 5 .cfi_endproc This is the only relevant difference compared to a nios2 toolchain where libssp is enabled and available (nios2 is an example). "CFI" stand for "Control Flow Integrity" and it seems that SSP support requires CFI target support (see [3] for some explanation). The SSP support seems to depends on CFI support, but the toolchain infrastructure is not detailed enough to handle the CFI dependency. The NiosII toolchains built with binutils < 2.30 are also affected by this issue. This patch improve the toolchain infrastructure by adding a new BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI blind option Disable SSP support for microblaze entirely. Disable SSP support for nios2 only with Binutils < 2.30. Fixes: https://gitlab.com/free-electrons/toolchains-builder/-/jobs/72006389 [1] https://gitlab.com/free-electrons/toolchains-builder/issues/1 [2] https://git.buildroot.net/buildroot/tree/package/gcc/gcc.mk?h=2018.05#n275 [3] https://grsecurity.net/rap_faq.php Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com> [Thomas: adjust how the BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI option is expressed.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2018-09-08 08:41:39 -06:00
config BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI
bool
default y
depends on !BR2_microblaze
choice
prompt "Binutils Version"
default BR2_BINUTILS_VERSION_2_38_X if !BR2_arc
default BR2_BINUTILS_VERSION_ARC if BR2_arc
help
Select the version of binutils you wish to use.
config BR2_BINUTILS_VERSION_2_37_X
bool "binutils 2.37"
package/binutils: prevent selecting 2.37 for AVX512 systems Support for the AVX512FP16 instructions was added in binutils 2.38. See the binutils 2.38 releases notes [0] that state: X86: [...] * Add support for Intel AVX512_FP16 instructions. [0] https://sourceware.org/pipermail/binutils/2022-February/119721.html It turns out that when building GCC 12.x, some of these AVX512FP16 instructions are now used, and therefore when binutils < 2.38 is used, the build fails as the assembler does not recognize those instructions: /tmp/ccChzL2g.s: Assembler messages: /tmp/ccChzL2g.s:20: Error: no such instruction: `vmovw 24(%esp),%xmm2' /tmp/ccChzL2g.s:21: Error: no such instruction: `vmovw 28(%esp),%xmm3' /tmp/ccChzL2g.s:22: Error: no such instruction: `vmovw 32(%esp),%xmm4' /tmp/ccChzL2g.s:23: Error: no such instruction: `vmovw 36(%esp),%xmm5' /tmp/ccChzL2g.s:30: Error: no such instruction: `vcvtsh2ss %xmm2,%xmm6,%xmm6' /tmp/ccChzL2g.s:36: Error: no such instruction: `vcvtsh2ss %xmm3,%xmm6,%xmm6' /tmp/ccChzL2g.s:42: Error: no such instruction: `vcvtsh2ss %xmm4,%xmm7,%xmm7' /tmp/ccChzL2g.s:48: Error: no such instruction: `vcvtsh2ss %xmm5,%xmm1,%xmm1' /tmp/ccChzL2g.s:80: Error: no such instruction: `vcvtss2sh (%esp),%xmm1,%xmm1' /tmp/ccChzL2g.s:96: Error: no such instruction: `vcvtss2sh (%esp),%xmm0,%xmm0' /tmp/ccChzL2g.s:100: Error: no such instruction: `vucomish %xmm1,%xmm1' /tmp/ccChzL2g.s:103: Error: no such instruction: `vucomish %xmm0,%xmm0' /tmp/ccChzL2g.s:122: Error: no such instruction: `vucomish %xmm2,%xmm2' The same issue does not occur with GCC 11.x, but nothing prevents other packages than GCC to use those instructions, so the problem really lies on the binutils side missing the support for those instructions. Also, in Buildroot, we do not distinguish AVX512 in general from AVX512FP16 specifically, so our only option is to make binutils 2.37 unavailable for AVX512 systems even if some of them perhaps don't support AVX512FP16 anyway. This seems like a reasonable trade-off, as binutils 2.38 is anyway already the default in Buildroot, and AVX512-capable systems are fairly recent, and therefore using a recent binutils version should not be a problem on these platforms. Fixes: http://autobuild.buildroot.net/results/eb6e28c934654e6d714973415a2fb452f9580279/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
2022-10-26 11:54:29 -06:00
# AVX512FP16 instructions were not supported before binutils
# 2.38
depends on !BR2_X86_CPU_HAS_AVX512
config BR2_BINUTILS_VERSION_2_38_X
bool "binutils 2.38"
config BR2_BINUTILS_VERSION_2_39_X
bool "binutils 2.39"
config BR2_BINUTILS_VERSION_ARC
bool "binutils arc (2.34.50)"
depends on BR2_arc
endchoice
config BR2_BINUTILS_VERSION
string
default "arc-2020.09-release" if BR2_BINUTILS_VERSION_ARC
default "2.37" if BR2_BINUTILS_VERSION_2_37_X
default "2.38" if BR2_BINUTILS_VERSION_2_38_X
default "2.39" if BR2_BINUTILS_VERSION_2_39_X
config BR2_BINUTILS_GPROFNG
bool "gprofng support"
depends on BR2_BINUTILS_VERSION_2_39_X
help
This option enables support for gprofng, a new profiler.
config BR2_BINUTILS_EXTRA_CONFIG_OPTIONS
2006-07-16 21:53:12 -06:00
string "Additional binutils options"
default ""
help
Any additional binutils options you may want to include.