2022-06-05 21:42:54 +02:00
|
|
|
config BR2_PACKAGE_GLIBC_ARCH_SUPPORTS
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_arm
|
|
|
|
|
default y if BR2_armeb
|
|
|
|
|
default y if BR2_aarch64
|
|
|
|
|
default y if BR2_aarch64_be
|
|
|
|
|
default y if BR2_i386
|
|
|
|
|
default y if BR2_mips
|
|
|
|
|
default y if BR2_mipsel
|
|
|
|
|
default y if BR2_mips64
|
|
|
|
|
default y if BR2_mips64el
|
|
|
|
|
default y if BR2_or1k
|
|
|
|
|
default y if BR2_powerpc
|
|
|
|
|
default y if BR2_powerpc64
|
|
|
|
|
default y if BR2_powerpc_power8
|
|
|
|
|
default y if BR2_riscv
|
|
|
|
|
default y if BR2_s390x
|
|
|
|
|
default y if BR2_sh
|
|
|
|
|
default y if BR2_sparc64
|
|
|
|
|
default y if BR2_x86_64
|
|
|
|
|
default y if BR2_microblaze
|
|
|
|
|
default y if BR2_nios2
|
|
|
|
|
default y if BR2_arc && BR2_ARC_ATOMIC_EXT
|
|
|
|
|
default y if BR2_csky
|
|
|
|
|
depends on !BR2_powerpc_SPE
|
|
|
|
|
depends on BR2_RISCV_ISA_RVA || !BR2_riscv
|
|
|
|
|
depends on BR2_USE_MMU
|
|
|
|
|
|
|
|
|
|
config BR2_PACKAGE_GLIBC_SUPPORTS
|
|
|
|
|
bool
|
|
|
|
|
default y if BR2_PACKAGE_GLIBC_ARCH_SUPPORTS
|
|
|
|
|
depends on !BR2_STATIC_LIBS
|
|
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_2
|
|
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_10 || !BR2_powerpc64le
|
|
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_5 || !BR2_MIPS_NAN_2008
|
|
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_0 || !BR2_RISCV_64
|
|
|
|
|
depends on BR2_TOOLCHAIN_HEADERS_AT_LEAST_5_1 || !BR2_arc
|
|
|
|
|
|
2014-02-10 18:43:46 +01:00
|
|
|
if BR2_TOOLCHAIN_BUILDROOT_GLIBC
|
|
|
|
|
|
2020-01-10 23:38:08 +01:00
|
|
|
comment "Glibc Options"
|
|
|
|
|
|
2014-07-25 22:06:27 +02:00
|
|
|
config BR2_PACKAGE_GLIBC
|
|
|
|
|
bool
|
|
|
|
|
default y
|
2015-12-30 00:10:38 +01:00
|
|
|
select BR2_PACKAGE_LINUX_HEADERS
|
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 16:41:39 +02:00
|
|
|
select BR2_TOOLCHAIN_HAS_SSP if BR2_PACKAGE_HOST_BINUTILS_SUPPORTS_CFI
|
2018-10-15 17:14:34 +02:00
|
|
|
help
|
|
|
|
|
https://www.gnu.org/software/libc/
|
2019-11-21 13:31:20 +01:00
|
|
|
|
package/glibc: allow runing on kernels older than used for the headers
Currently, we configure glibc to not add compatibility support for
kernels older than the one used for the headers. This is on the
expectation that the system will never run on a kernel that is older
than the one used for the headers or, when Buildroot builds the kernel,
on another, older kernel.
However, in some situations, it is possible to build for a generic
system, where the kernel may be a different version. This can be the
case, for example, when Building an image that is to be used in a
container that can run on a range of machines each with different kernel
versions. In such a case, it is interesting to build glibc in a way as
to take better advantage of the newer kernels, and thus using newer
kernel headers, while still allowing running on older kernels, and thus
carrying more compatibility code.
We add an option to glibc to allow the user to enable compatibility
shims. To simplify the case, when that option is enabled, we just let
glibc enable as old compatibility shims as supported by the current
architecture.
The code size increase is very small. For an ARM Cortex-A7, with
gcc-10.3.0, the delta is as follows (other files installed by glibc had
no size delta; sizes in bytes):
file | no compat | compat | delta
----------------------+-----------+-----------+-------
ld-linux-armhf.so.3 | 200216 | 200284 | + 68
libc.so.6 | 1814496 | 1823120 | +8624
------+-------
Total | +8692
No runtime overhead has been measured; the overhead is most probably
in the measurement noise. Indeed, the compatibility shims are very
lightweight. For example, there are 9 arch-generic shims:
renameat2(), execveat(), mlock2(), statx(), faccessat2(),
close_range(), time64-related syscall shenanigans, a waitid()
feature, and a futex operation (LOCK_PI2)
and then each arch may define a few others. i386 has less than 20
(mostly related to socket options, and one for the ordering of the
clone() arguments), while ARM seems to have only two (mlock2() and a
configurable futex feature).
Note: however, as Arnout pointed out, some programs may still actually
fail to run even with such compatibility shim, if they really expect the
shimed syscalls to really exist and have no fallback (and/or no proper
error-handling). Still, in the vast majority of cases, those
compatibility shims are enough to have a system running.
Signed-off-by: Yann E. MORIN <yann.morin@orange.com>
Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2022-02-02 14:48:38 +01:00
|
|
|
config BR2_PACKAGE_GLIBC_KERNEL_COMPAT
|
|
|
|
|
bool "Enable compatibiltiy shims to run on older kernels"
|
|
|
|
|
help
|
|
|
|
|
Say 'y' here if you plan on running your system on a kernel
|
|
|
|
|
older than the version used for the toolchain headers.
|
|
|
|
|
|
|
|
|
|
Enabling those compatibility shims may generate a slightly
|
|
|
|
|
bigger and slightly slower glibc library.
|
|
|
|
|
|
|
|
|
|
The oldest supported kernel version depends on the
|
|
|
|
|
architecture.
|
|
|
|
|
|
2019-11-21 13:31:20 +01:00
|
|
|
config BR2_PACKAGE_GLIBC_UTILS
|
|
|
|
|
bool "Install glibc utilities"
|
|
|
|
|
help
|
|
|
|
|
Enabling this option will compile and install the getconf,
|
2019-11-26 09:55:41 +01:00
|
|
|
ldconfig, ldd and locale glibc utilities for the target.
|
2019-12-19 12:10:24 +01:00
|
|
|
|
|
|
|
|
endif # BR2_TOOLCHAIN_BUILDROOT_GLIBC
|
