* [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53
@ 2020-05-21 16:15 Khem Raj
2020-05-21 16:15 ` [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs Khem Raj
` (9 more replies)
0 siblings, 10 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/tune-cortexa55.inc | 17 ++++++++++++++
.../include/tune-cortexa73-cortexa53.inc | 23 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa55.inc
create mode 100644 meta/conf/machine/include/tune-cortexa73-cortexa53.inc
diff --git a/meta/conf/machine/include/tune-cortexa55.inc b/meta/conf/machine/include/tune-cortexa55.inc
new file mode 100644
index 0000000000..8242cc9cef
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -0,0 +1,17 @@
+DEFAULTTUNE ?= "cortexa55"
+
+TUNEVALID[cortexa55] = "Enable Cortex-A55 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa55', ' -mcpu=cortex-a55', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "cortexa55 cortexa55-crypto"
+ARMPKGARCH_tune-cortexa55 = "cortexa55"
+ARMPKGARCH_tune-cortexa55-crypto = "cortexa55"
+TUNE_FEATURES_tune-cortexa55 = "aarch64 cortexa55 crc"
+TUNE_FEATURES_tune-cortexa55-crypto = "aarch64 cortexa55 crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa55 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa55"
+PACKAGE_EXTRA_ARCHS_tune-cortexa55-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55 cortexa55-crypto"
+BASE_LIB_tune-cortexa55 = "lib64"
+BASE_LIB_tune-cortexa55-crypto = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
new file mode 100644
index 0000000000..8df418227f
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
@@ -0,0 +1,23 @@
+DEFAULTTUNE ?= "cortexa73-cortexa53"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+TUNEVALID[cortexa73-cortexa53] = "Enable big.LITTLE Cortex-A73.Cortex-A53 specific processor optimizations"
+
+TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
+
+MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", "cortexa73-cortexa53:", "" ,d)}"
+
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", " -mtune=cortex-a73.cortex-a53", "", d)}"
+
+# cortexa73.cortexa53 implies crc support
+AVAILTUNES += "cortexa73-cortexa53 cortexa73-cortexa53-crypto"
+ARMPKGARCH_tune-cortexa73-cortexa53 = "cortexa73-cortexa53"
+ARMPKGARCH_tune-cortexa73-cortexa53-crypto = "cortexa73-cortexa53"
+TUNE_FEATURES_tune-cortexa73-cortexa53 = "${TUNE_FEATURES_tune-armv8a-crc} cortexa73-cortexa53"
+TUNE_FEATURES_tune-cortexa73-cortexa53-crypto = "${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa73-cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa73-cortexa53"
+PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa73-cortexa53 cortexa73-cortexa53-crypto"
+BASE_LIB_tune-cortexa73-cortexa53 = "lib64"
+BASE_LIB_tune-cortexa73-cortexa53-crypto = "lib64"
+
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 03/10] glibc: Update to latest on 2.31 branch Khem Raj
` (8 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
gcc-runtime/libatomic explicitly add -march=armv8-a+lse for all arch64
but cortex-a55 is armv8.2-a, which essentially conflicts, so let gcc
override it by not forcing the -mcpu option from TUNE_CCARGS
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/recipes-devtools/gcc/gcc-runtime.inc | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc
index ace706dbf4..d9a4e483cc 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -18,6 +18,10 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
EXTRA_OECONF_append_libc-newlib = " --with-newlib"
+# cortex-a55 is ARMv8.2-a based but libatomic explicitly asks for -march=armv8.1-a
+# which caused -march conflicts in gcc
+TUNE_CCARGS_remove = "-mcpu=cortex-a55+crc -mcpu=cortex-a55 -mcpu=cortex-a55+crc+crypto"
+
# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
EXTRA_OECONF_append_armeb = " libat_cv_have_ifunc=no "
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 03/10] glibc: Update to latest on 2.31 branch
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
2020-05-21 16:15 ` [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 04/10] wayland: fix condition for strndup detection Khem Raj
` (7 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
There are few fixes specifically for compiling with gcc10 that are good
to have, before hitting them later
Backport build fix from master for aarch64 with gcc10
Drop CVE-2020-10029 patch its already applied on latest 2.31 branch
latest glibc 2.31 added fix for __getauxval/aarch64 issue
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/recipes-core/glibc/glibc-version.inc | 2 +-
.../0030-Improve-IFUNC-check-BZ-25506.patch | 47 -----
...-with-GCC-10-when-long-double-double.patch | 170 ------------------
.../glibc/glibc/CVE-2020-10029.patch | 128 -------------
meta/recipes-core/glibc/glibc_2.31.bb | 3 -
5 files changed, 1 insertion(+), 349 deletions(-)
delete mode 100644 meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
delete mode 100644 meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
delete mode 100644 meta/recipes-core/glibc/glibc/CVE-2020-10029.patch
diff --git a/meta/recipes-core/glibc/glibc-version.inc b/meta/recipes-core/glibc/glibc-version.inc
index 4c72eedf41..c2d68979eb 100644
--- a/meta/recipes-core/glibc/glibc-version.inc
+++ b/meta/recipes-core/glibc/glibc-version.inc
@@ -1,6 +1,6 @@
SRCBRANCH ?= "release/2.31/master"
PV = "2.31+git${SRCPV}"
-SRCREV_glibc ?= "71f2b249a28e17eac0e47c53af44d5c5b65101aa"
+SRCREV_glibc ?= "109474122400ca7d60782b131dc867a5c1f2fe55"
SRCREV_localedef ?= "cd9f958c4c94a638fa7b2b4e21627364f1a1a655"
GLIBC_GIT_URI ?= "git://sourceware.org/git/glibc.git"
diff --git a/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch b/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
deleted file mode 100644
index 1cb398d2bc..0000000000
--- a/meta/recipes-core/glibc/glibc/0030-Improve-IFUNC-check-BZ-25506.patch
+++ /dev/null
@@ -1,47 +0,0 @@
-From 87a698a21646b7ee620923ef5ffa9735471a8ddd Mon Sep 17 00:00:00 2001
-From: Fangrui Song <maskray@google.com>
-Date: Tue, 4 Feb 2020 21:55:44 -0800
-Subject: [PATCH] Improve IFUNC check [BZ #25506]
-
-GNU ld's RISCV port does not support IFUNC. ld -no-pie produces no
-relocation and the test passed incorrectly. Be more rigid by testing
-IRELATIVE explicitly.
-
-Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=87a698a21646b7ee620923ef5ffa9735471a8ddd]
-Tested-by: Aurelien Jarno <aurelien@aurel32.net>
-Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
----
- configure | 2 +-
- configure.ac | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/configure b/configure
-index b959d2d988..3b98ec312f 100755
---- a/configure
-+++ b/configure
-@@ -4035,7 +4035,7 @@ if ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS \
- -o conftest conftest.S 1>&5 2>&5; then
- # Do a link to see if the backend supports IFUNC relocs.
- $READELF -r conftest 1>&5
-- LC_ALL=C $READELF -r conftest | grep 'no relocations' >/dev/null || {
-+ LC_ALL=C $READELF -Wr conftest | grep -q 'IRELATIVE\|R_SPARC_JMP_IREL' && {
- libc_cv_ld_gnu_indirect_function=yes
- }
- fi
-diff --git a/configure.ac b/configure.ac
-index 49b900c1ed..e20034f301 100644
---- a/configure.ac
-+++ b/configure.ac
-@@ -649,7 +649,7 @@ if ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS \
- -o conftest conftest.S 1>&AS_MESSAGE_LOG_FD 2>&AS_MESSAGE_LOG_FD; then
- # Do a link to see if the backend supports IFUNC relocs.
- $READELF -r conftest 1>&AS_MESSAGE_LOG_FD
-- LC_ALL=C $READELF -r conftest | grep 'no relocations' >/dev/null || {
-+ LC_ALL=C $READELF -Wr conftest | grep -q 'IRELATIVE\|R_SPARC_JMP_IREL' && {
- libc_cv_ld_gnu_indirect_function=yes
- }
- fi
---
-2.25.1
-
diff --git a/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch b/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
deleted file mode 100644
index 72622961ad..0000000000
--- a/meta/recipes-core/glibc/glibc/0031-Fix-build-with-GCC-10-when-long-double-double.patch
+++ /dev/null
@@ -1,170 +0,0 @@
-From 49348beafe9ba150c9bd48595b3f372299bddbb0 Mon Sep 17 00:00:00 2001
-From: Joseph Myers <joseph@codesourcery.com>
-Date: Tue, 17 Mar 2020 22:57:42 +0000
-Subject: [PATCH] Fix build with GCC 10 when long double = double.
-
-On platforms where long double has the same ABI as double, glibc
-defines long double functions as aliases for the corresponding double
-functions. The declarations of those functions in <math.h> are
-disabled to avoid problems with aliases having incompatible types, but
-GCC 10 now gives errors for incompatible types when the long double
-function is known to GCC as a built-in function, not just when there
-is an incompatible header declaration.
-
-This patch fixes those errors by using appropriate
--fno-builtin-<function> options to compile the double functions. The
-list of CFLAGS-* settings is an appropriately adapted version of that
-in sysdeps/ieee754/ldbl-opt/Makefile used there for building nldbl-*.c
-files; in particular, the options are used even if GCC does not
-currently have a built-in function of a given function, so that adding
-such a built-in function in future will not break the glibc build.
-Thus, various of the CFLAGS-* settings are only for future-proofing
-and may not currently be needed (and it's possible some could be
-irrelevant for other reasons).
-
-Tested with build-many-glibcs.py for arm-linux-gnueabi (compilers and
-glibcs builds), where it fixes the build that previously failed.
-
-Upstream-Status: Backport [https://sourceware.org/git/?p=glibc.git;a=commit;h=49348beafe9ba150c9bd48595b3f372299bddbb0]
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-
----
- math/Makefile | 122 ++++++++++++++++++++++++++++++++++++++++++++++++++
- 1 file changed, 122 insertions(+)
-
-diff --git a/math/Makefile b/math/Makefile
-index 84a8b94c74..0a5a40430e 100644
---- a/math/Makefile
-+++ b/math/Makefile
-@@ -650,6 +650,128 @@ ifneq ($(long-double-fcts),yes)
- # We won't compile the `long double' code at all. Tell the `double' code
- # to define aliases for the `FUNCl' names.
- math-CPPFLAGS += -DNO_LONG_DOUBLE
-+# GCC 10 diagnoses aliases with types conflicting with built-in
-+# functions.
-+CFLAGS-w_acos.c += -fno-builtin-acosl
-+CFLAGS-w_acosh.c += -fno-builtin-acoshl
-+CFLAGS-w_asin.c += -fno-builtin-asinl
-+CFLAGS-s_asinh.c += -fno-builtin-asinhl
-+CFLAGS-s_atan.c += -fno-builtin-atanl
-+CFLAGS-w_atan2.c += -fno-builtin-atan2l
-+CFLAGS-w_atanh.c += -fno-builtin-atanhl
-+CFLAGS-s_cabs.c += -fno-builtin-cabsl
-+CFLAGS-s_cacos.c += -fno-builtin-cacosl
-+CFLAGS-s_cacosh.c += -fno-builtin-cacoshl
-+CFLAGS-s_canonicalize.c += -fno-builtin-canonicalizel
-+CFLAGS-s_carg.c += -fno-builtin-cargl
-+CFLAGS-s_casin.c += -fno-builtin-casinl
-+CFLAGS-s_casinh.c += -fno-builtin-casinhl
-+CFLAGS-s_catan.c += -fno-builtin-catanl
-+CFLAGS-s_catanh.c += -fno-builtin-catanhl
-+CFLAGS-s_cbrt.c += -fno-builtin-cbrtl
-+CFLAGS-s_ccos.c += -fno-builtin-ccosl
-+CFLAGS-s_ccosh.c += -fno-builtin-ccoshl
-+CFLAGS-s_ceil.c += -fno-builtin-ceill
-+CFLAGS-s_cexp.c += -fno-builtin-cexpl
-+CFLAGS-s_cimag.c += -fno-builtin-cimagl
-+CFLAGS-s_clog.c += -fno-builtin-clogl
-+CFLAGS-s_clog10.c += -fno-builtin-clog10l
-+CFLAGS-s_conj.c += -fno-builtin-conjl
-+CFLAGS-s_copysign.c += -fno-builtin-copysignl
-+CFLAGS-s_cos.c += -fno-builtin-cosl
-+CFLAGS-w_cosh.c += -fno-builtin-coshl
-+CFLAGS-s_cpow.c += -fno-builtin-cpowl
-+CFLAGS-s_cproj.c += -fno-builtin-cprojl
-+CFLAGS-s_creal.c += -fno-builtin-creall
-+CFLAGS-s_csin.c += -fno-builtin-csinl
-+CFLAGS-s_csinh.c += -fno-builtin-csinhl
-+CFLAGS-s_csqrt.c += -fno-builtin-csqrtl
-+CFLAGS-s_ctan.c += -fno-builtin-ctanl
-+CFLAGS-s_ctanh.c += -fno-builtin-ctanhl
-+CFLAGS-s_dadd.c += -fno-builtin-daddl
-+CFLAGS-s_ddiv.c += -fno-builtin-ddivl
-+CFLAGS-s_dmul.c += -fno-builtin-dmull
-+CFLAGS-s_dsub.c += -fno-builtin-dsubl
-+CFLAGS-s_erf.c += -fno-builtin-erfl
-+CFLAGS-s_erfc.c += -fno-builtin-erfcl
-+CFLAGS-e_exp.c += -fno-builtin-expl
-+CFLAGS-w_exp10.c += -fno-builtin-exp10l
-+CFLAGS-e_exp2.c += -fno-builtin-exp2l
-+CFLAGS-s_expm1.c += -fno-builtin-expm1l
-+CFLAGS-s_fabs.c += -fno-builtin-fabsl
-+CFLAGS-s_fadd.c += -fno-builtin-faddl
-+CFLAGS-s_fdim.c += -fno-builtin-fdiml
-+CFLAGS-s_fdiv.c += -fno-builtin-fdivl
-+CFLAGS-s_finite.c += -fno-builtin-finitel
-+CFLAGS-s_floor.c += -fno-builtin-floorl
-+CFLAGS-s_fma.c += -fno-builtin-fmal
-+CFLAGS-s_fmax.c += -fno-builtin-fmaxl
-+CFLAGS-s_fmaxmag.c += -fno-builtin-fmaxmagl
-+CFLAGS-s_fmin.c += -fno-builtin-fminl
-+CFLAGS-s_fminmag.c += -fno-builtin-fminmagl
-+CFLAGS-w_fmod.c += -fno-builtin-fmodl
-+CFLAGS-s_fmul.c += -fno-builtin-fmull
-+CFLAGS-s_frexp.c += -fno-builtin-frexpl
-+CFLAGS-s_fromfp.c += -fno-builtin-fromfpl
-+CFLAGS-s_fromfpx.c += -fno-builtin-fromfpxl
-+CFLAGS-s_fsub.c += -fno-builtin-fsubl
-+CFLAGS-s_gamma.c += -fno-builtin-gammal
-+CFLAGS-s_getpayload.c += -fno-builtin-getpayloadl
-+CFLAGS-w_hypot.c += -fno-builtin-hypotl
-+CFLAGS-w_ilogb.c += -fno-builtin-ilogbl
-+CFLAGS-s_isinf.c += -fno-builtin-isinfl
-+CFLAGS-s_isnan.c += -fno-builtin-isnanl
-+CFLAGS-w_j0.c += -fno-builtin-j0l
-+CFLAGS-w_j1.c += -fno-builtin-j1l
-+CFLAGS-w_jn.c += -fno-builtin-jnl
-+CFLAGS-s_ldexp.c += -fno-builtin-ldexpl
-+CFLAGS-w_lgamma.c += -fno-builtin-lgammal
-+CFLAGS-w_lgamma_r.c += -fno-builtin-lgammal_r
-+CFLAGS-w_llogb.c += -fno-builtin-llogbl
-+CFLAGS-s_llrint.c += -fno-builtin-llrintl
-+CFLAGS-s_llround.c += -fno-builtin-llroundl
-+CFLAGS-e_log.c += -fno-builtin-logl
-+CFLAGS-w_log10.c += -fno-builtin-log10l
-+CFLAGS-w_log1p.c += -fno-builtin-log1pl
-+CFLAGS-e_log2.c += -fno-builtin-log2l
-+CFLAGS-s_logb.c += -fno-builtin-logbl
-+CFLAGS-s_lrint.c += -fno-builtin-lrintl
-+CFLAGS-s_lround.c += -fno-builtin-lroundl
-+CFLAGS-s_modf.c += -fno-builtin-modfl
-+CFLAGS-s_nan.c += -fno-builtin-nanl
-+CFLAGS-s_nearbyint.c += -fno-builtin-nearbyintl
-+CFLAGS-s_nextafter.c += -fno-builtin-nextafterl
-+CFLAGS-s_nextdown.c += -fno-builtin-nextdownl
-+CFLAGS-s_nexttoward.c += -fno-builtin-nexttoward -fno-builtin-nexttowardl
-+CFLAGS-s_nexttowardf.c += -fno-builtin-nexttowardf
-+CFLAGS-s_nextup.c += -fno-builtin-nextupl
-+CFLAGS-e_pow.c += -fno-builtin-powl
-+CFLAGS-w_remainder.c += -fno-builtin-remainderl -fno-builtin-dreml
-+CFLAGS-s_remquo.c += -fno-builtin-remquol
-+CFLAGS-s_rint.c += -fno-builtin-rintl
-+CFLAGS-s_round.c += -fno-builtin-roundl
-+CFLAGS-s_roundeven.c += -fno-builtin-roundevenl
-+CFLAGS-w_scalb.c += -fno-builtin-scalbl
-+CFLAGS-w_scalbln.c += -fno-builtin-scalblnl
-+CFLAGS-s_scalbn.c += -fno-builtin-scalbnl
-+CFLAGS-s_setpayload.c += -fno-builtin-setpayloadl
-+CFLAGS-s_setpayloadsig.c += -fno-builtin-setpayloadsigl
-+CFLAGS-s_significand.c += -fno-builtin-significandl
-+CFLAGS-s_sin.c += -fno-builtin-sinl
-+CFLAGS-s_sincos.c += -fno-builtin-sincosl
-+CFLAGS-w_sinh.c += -fno-builtin-sinhl
-+CFLAGS-w_sqrt.c += -fno-builtin-sqrtl
-+CFLAGS-s_tan.c += -fno-builtin-tanl
-+CFLAGS-s_tanh.c += -fno-builtin-tanhl
-+CFLAGS-w_tgamma.c += -fno-builtin-tgammal
-+CFLAGS-s_totalorder.c += -fno-builtin-totalorderl
-+CFLAGS-s_totalordermag.c += -fno-builtin-totalordermagl
-+CFLAGS-s_trunc.c += -fno-builtin-truncl
-+CFLAGS-s_ufromfp.c += -fno-builtin-ufromfpl
-+CFLAGS-s_ufromfpx.c += -fno-builtin-ufromfpxl
-+CFLAGS-s_y0.c += -fno-builtin-y0l
-+CFLAGS-s_y1.c += -fno-builtin-y1l
-+CFLAGS-s_yn.c += -fno-builtin-ynl
- endif
-
- # These files quiet sNaNs in a way that is optimized away without
---
-2.26.0
-
diff --git a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch b/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch
deleted file mode 100644
index 22a15f5fdc..0000000000
--- a/meta/recipes-core/glibc/glibc/CVE-2020-10029.patch
+++ /dev/null
@@ -1,128 +0,0 @@
-From ce265ec5bc25ec35fba53807abac1b0c8469895e Mon Sep 17 00:00:00 2001
-From: Joseph Myers <joseph@codesourcery.com>
-Date: Wed, 12 Feb 2020 23:31:56 +0000
-Subject: [PATCH] Avoid ldbl-96 stack corruption from range reduction of
-
- pseudo-zero (bug 25487).
-
-Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero
-argument (an representation where all the significand bits, including
-the explicit high bit, are zero, but the exponent is not zero, which
-is not a valid representation for the long double type).
-
-Although this is not a valid long double representation, existing
-practice in this area (see bug 4586, originally marked invalid but
-subsequently fixed) is that we still seek to avoid invalid memory
-accesses as a result, in case of programs that treat arbitrary binary
-data as long double representations, although the invalid
-representations of the ldbl-96 format do not need to be consistently
-handled the same as any particular valid representation.
-
-This patch makes the range reduction detect pseudo-zero and unnormal
-representations that would otherwise go to __kernel_rem_pio2, and
-returns a NaN for them instead of continuing with the range reduction
-process. (Pseudo-zero and unnormal representations whose unbiased
-exponent is less than -1 have already been safely returned from the
-function before this point without going through the rest of range
-reduction.) Pseudo-zero representations would previously result in
-the value passed to __kernel_rem_pio2 being all-zero, which is
-definitely unsafe; unnormal representations would previously result in
-a value passed whose high bit is zero, which might well be unsafe
-since that is not a form of input expected by __kernel_rem_pio2.
-
-Tested for x86_64.
-
-CVE: CVE-2020-10029
-Upstream-Status: Backport [https://sourceware.org/git/gitweb.cgi?p=glibc.git;
-a=patch;h=9333498794cde1d5cca518badf79533a24114b6f]
-Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
-
----
- sysdeps/ieee754/ldbl-96/Makefile | 3 ++-
- sysdeps/ieee754/ldbl-96/e_rem_pio2l.c | 12 +++++++++
- sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c | 41 ++++++++++++++++++++++++++++++
- 3 files changed, 55 insertions(+), 1 deletion(-)
- create mode 100644 sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c
-
-diff --git a/sysdeps/ieee754/ldbl-96/Makefile b/sysdeps/ieee754/ldbl-96/Makefile
-index b103254..052c1c7 100644
---- a/sysdeps/ieee754/ldbl-96/Makefile
-+++ b/sysdeps/ieee754/ldbl-96/Makefile
-@@ -17,5 +17,6 @@
- # <https://www.gnu.org/licenses/>.
-
- ifeq ($(subdir),math)
--tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96
-+tests += test-canonical-ldbl-96 test-totalorderl-ldbl-96 test-sinl-pseudo
-+CFLAGS-test-sinl-pseudo.c += -fstack-protector-all
- endif
-diff --git a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c
-index 805de22..1aeccb4 100644
---- a/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c
-+++ b/sysdeps/ieee754/ldbl-96/e_rem_pio2l.c
-@@ -210,6 +210,18 @@ __ieee754_rem_pio2l (long double x, long double *y)
- return 0;
- }
-
-+ if ((i0 & 0x80000000) == 0)
-+ {
-+ /* Pseudo-zero and unnormal representations are not valid
-+ representations of long double. We need to avoid stack
-+ corruption in __kernel_rem_pio2, which expects input in a
-+ particular normal form, but those representations do not need
-+ to be consistently handled like any particular floating-point
-+ value. */
-+ y[1] = y[0] = __builtin_nanl ("");
-+ return 0;
-+ }
-+
- /* Split the 64 bits of the mantissa into three 24-bit integers
- stored in a double array. */
- exp = j0 - 23;
-diff --git a/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c
-new file mode 100644
-index 0000000..f59b977
---- /dev/null
-+++ b/sysdeps/ieee754/ldbl-96/test-sinl-pseudo.c
-@@ -0,0 +1,41 @@
-+/* Test sinl for pseudo-zeros and unnormals for ldbl-96 (bug 25487).
-+ Copyright (C) 2020 Free Software Foundation, Inc.
-+ This file is part of the GNU C Library.
-+
-+ The GNU C Library is free software; you can redistribute it and/or
-+ modify it under the terms of the GNU Lesser General Public
-+ License as published by the Free Software Foundation; either
-+ version 2.1 of the License, or (at your option) any later version.
-+
-+ The GNU C Library is distributed in the hope that it will be useful,
-+ but WITHOUT ANY WARRANTY; without even the implied warranty of
-+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-+ Lesser General Public License for more details.
-+
-+ You should have received a copy of the GNU Lesser General Public
-+ License along with the GNU C Library; if not, see
-+ <https://www.gnu.org/licenses/>. */
-+
-+#include <math.h>
-+#include <math_ldbl.h>
-+#include <stdint.h>
-+
-+static int
-+do_test (void)
-+{
-+ for (int i = 0; i < 64; i++)
-+ {
-+ uint64_t sig = i == 63 ? 0 : 1ULL << i;
-+ long double ld;
-+ SET_LDOUBLE_WORDS (ld, 0x4141,
-+ sig >> 32, sig & 0xffffffffULL);
-+ /* The requirement is that no stack overflow occurs when the
-+ pseudo-zero or unnormal goes through range reduction. */
-+ volatile long double ldr;
-+ ldr = sinl (ld);
-+ (void) ldr;
-+ }
-+ return 0;
-+}
-+
-+#include <support/test-driver.c>
diff --git a/meta/recipes-core/glibc/glibc_2.31.bb b/meta/recipes-core/glibc/glibc_2.31.bb
index 6605fd3967..2032311b27 100644
--- a/meta/recipes-core/glibc/glibc_2.31.bb
+++ b/meta/recipes-core/glibc/glibc_2.31.bb
@@ -40,9 +40,6 @@ SRC_URI = "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
file://0027-intl-Emit-no-lines-in-bison-generated-files.patch \
file://0028-inject-file-assembly-directives.patch \
file://0029-locale-prevent-maybe-uninitialized-errors-with-Os-BZ.patch \
- file://CVE-2020-10029.patch \
- file://0030-Improve-IFUNC-check-BZ-25506.patch \
- file://0031-Fix-build-with-GCC-10-when-long-double-double.patch \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build-${TARGET_SYS}"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 04/10] wayland: fix condition for strndup detection
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
2020-05-21 16:15 ` [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs Khem Raj
2020-05-21 16:15 ` [dunfell][ 03/10] glibc: Update to latest on 2.31 branch Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 05/10] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55 Khem Raj
` (6 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
current check does not work with gcc10
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
.../0001-build-Fix-strndup-detection-on-MinGW.patch | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/meta/recipes-graphics/wayland/wayland/0001-build-Fix-strndup-detection-on-MinGW.patch b/meta/recipes-graphics/wayland/wayland/0001-build-Fix-strndup-detection-on-MinGW.patch
index e445838750..c2ceae4a47 100644
--- a/meta/recipes-graphics/wayland/wayland/0001-build-Fix-strndup-detection-on-MinGW.patch
+++ b/meta/recipes-graphics/wayland/wayland/0001-build-Fix-strndup-detection-on-MinGW.patch
@@ -17,8 +17,6 @@ Upstream-Status: Submitted [https://gitlab.freedesktop.org/wayland/wayland/merge
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-diff --git a/meson.build b/meson.build
-index 26b084f..c05d019 100644
--- a/meson.build
+++ b/meson.build
@@ -36,11 +36,11 @@ have_funcs = [
@@ -30,10 +28,7 @@ index 26b084f..c05d019 100644
foreach f: have_funcs
config_h.set('HAVE_' + f.underscorify().to_upper(), cc.has_function(f))
endforeach
-+config_h.set('HAVE_STRNDUP', cc.has_function('strndup', prefix:'#include <string.h>'))
++config_h.set('HAVE_STRNDUP', cc.has_function('strndup') and cc.has_header_symbol('string.h', 'strndup'))
if get_option('libraries')
ffi_dep = dependency('libffi')
---
-2.17.1
-
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 05/10] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (2 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 04/10] wayland: fix condition for strndup detection Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 06/10] tune-cortexa57.inc: Add new tune file Khem Raj
` (5 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/tune-cortexa55.inc | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa55.inc b/meta/conf/machine/include/tune-cortexa55.inc
index 8242cc9cef..89032b59ec 100644
--- a/meta/conf/machine/include/tune-cortexa55.inc
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -6,12 +6,8 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa55', ' -mcpu=corte
require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
-AVAILTUNES += "cortexa55 cortexa55-crypto"
+AVAILTUNES += "cortexa55"
ARMPKGARCH_tune-cortexa55 = "cortexa55"
-ARMPKGARCH_tune-cortexa55-crypto = "cortexa55"
-TUNE_FEATURES_tune-cortexa55 = "aarch64 cortexa55 crc"
-TUNE_FEATURES_tune-cortexa55-crypto = "aarch64 cortexa55 crc crypto"
-PACKAGE_EXTRA_ARCHS_tune-cortexa55 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa55"
-PACKAGE_EXTRA_ARCHS_tune-cortexa55-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55 cortexa55-crypto"
+TUNE_FEATURES_tune-cortexa55 = "aarch64 cortexa55 crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa55 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
BASE_LIB_tune-cortexa55 = "lib64"
-BASE_LIB_tune-cortexa55-crypto = "lib64"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 06/10] tune-cortexa57.inc: Add new tune file
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (3 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 05/10] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55 Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 07/10] aarch64: Adjust big.LITTLE tune files to use -mcpu Khem Raj
` (4 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/tune-cortexa57.inc | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
create mode 100644 meta/conf/machine/include/tune-cortexa57.inc
diff --git a/meta/conf/machine/include/tune-cortexa57.inc b/meta/conf/machine/include/tune-cortexa57.inc
new file mode 100644
index 0000000000..645a5a7ef6
--- /dev/null
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -0,0 +1,17 @@
+DEFAULTTUNE ?= "cortexa57"
+
+TUNEVALID[cortexa57] = "Enable Cortex-A57 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa57', ' -mcpu=cortex-a57', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "cortexa57 cortexa57-crypto"
+ARMPKGARCH_tune-cortexa57 = "cortexa57"
+ARMPKGARCH_tune-cortexa57-crypto = "cortexa57"
+TUNE_FEATURES_tune-cortexa57 = "aarch64 cortexa57 crc"
+TUNE_FEATURES_tune-cortexa57-crypto = "aarch64 cortexa57 crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa57"
+PACKAGE_EXTRA_ARCHS_tune-cortexa57-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa57 cortexa57-crypto"
+BASE_LIB_tune-cortexa57 = "lib64"
+BASE_LIB_tune-cortexa57-crypto = "lib64"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 07/10] aarch64: Adjust big.LITTLE tune files to use -mcpu
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (4 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 06/10] tune-cortexa57.inc: Add new tune file Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH Khem Raj
` (3 subsequent siblings)
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
mcpu is more appropriate on aarch64 and generates more optimized code
forr a given SOC, unlike -march/-mtune combination as decribed here [1]
[1] https://community.arm.com/developer/tools-software/tools/b/tools-software-ides-blog/posts/compiler-flags-across-architectures-march-mtune-and-mcpu
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
.../conf/machine/include/tune-cortexa57-cortexa53.inc | 9 +++------
.../conf/machine/include/tune-cortexa72-cortexa53.inc | 11 ++++-------
.../conf/machine/include/tune-cortexa73-cortexa53.inc | 11 ++++-------
3 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
index d05e93f51e..ba4b073852 100644
--- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -1,18 +1,15 @@
DEFAULTTUNE ?= "cortexa57-cortexa53"
-require conf/machine/include/arm/arch-armv8a.inc
TUNEVALID[cortexa57-cortexa53] = "Enable big.LITTLE Cortex-A57.Cortex-A53 specific processor optimizations"
TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " -march=armv8-a", "" ,d)}"
-
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", " -mcpu=cortex-a57.cortex-a53", "", d)}"
MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", "cortexa57-cortexa53:", "" ,d)}"
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa57-cortexa53", " -mtune=cortex-a57.cortex-a53", "", d)}"
+require conf/machine/include/arm/arch-armv8a.inc
# Little Endian base configs
AVAILTUNES += "cortexa57-cortexa53"
ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
-TUNE_FEATURES_tune-cortexa57-cortexa53 = "${TUNE_FEATURES_tune-aarch64} cortexa57-cortexa53"
+TUNE_FEATURES_tune-cortexa57-cortexa53 = "aarch64 cortexa57-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index f208b98e3e..5c54aa33ea 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -1,21 +1,18 @@
DEFAULTTUNE ?= "cortexa72-cortexa53"
-require conf/machine/include/arm/arch-armv8a.inc
-
TUNEVALID[cortexa72-cortexa53] = "Enable big.LITTLE Cortex-A72.Cortex-A53 specific processor optimizations"
-
TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa72-cortexa53", " -mcpu=cortex-a72.cortex-a53", "", d)}"
MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa72-cortexa53", "cortexa72-cortexa53:", "" ,d)}"
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa72-cortexa53", " -mtune=cortex-a72.cortex-a53", "", d)}"
+require conf/machine/include/arm/arch-armv8a.inc
# cortexa72.cortexa53 implies crc support
AVAILTUNES += "cortexa72-cortexa53 cortexa72-cortexa53-crypto"
ARMPKGARCH_tune-cortexa72-cortexa53 = "cortexa72-cortexa53"
ARMPKGARCH_tune-cortexa72-cortexa53-crypto = "cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53 = "${TUNE_FEATURES_tune-armv8a-crc} cortexa72-cortexa53"
-TUNE_FEATURES_tune-cortexa72-cortexa53-crypto = "${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53 = "aarch64 crc cortexa72-cortexa53"
+TUNE_FEATURES_tune-cortexa72-cortexa53-crypto = "aarch64 crc crypto cortexa72-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 cortexa72-cortexa53-crypto"
BASE_LIB_tune-cortexa72-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
index 8df418227f..431d244fe2 100644
--- a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
@@ -1,21 +1,18 @@
DEFAULTTUNE ?= "cortexa73-cortexa53"
-require conf/machine/include/arm/arch-armv8a.inc
-
TUNEVALID[cortexa73-cortexa53] = "Enable big.LITTLE Cortex-A73.Cortex-A53 specific processor optimizations"
-
TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
-
MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", "cortexa73-cortexa53:", "" ,d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", " -mcpu=cortex-a73.cortex-a53", "", d)}"
-TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", " -mtune=cortex-a73.cortex-a53", "", d)}"
+require conf/machine/include/arm/arch-armv8a.inc
# cortexa73.cortexa53 implies crc support
AVAILTUNES += "cortexa73-cortexa53 cortexa73-cortexa53-crypto"
ARMPKGARCH_tune-cortexa73-cortexa53 = "cortexa73-cortexa53"
ARMPKGARCH_tune-cortexa73-cortexa53-crypto = "cortexa73-cortexa53"
-TUNE_FEATURES_tune-cortexa73-cortexa53 = "${TUNE_FEATURES_tune-armv8a-crc} cortexa73-cortexa53"
-TUNE_FEATURES_tune-cortexa73-cortexa53-crypto = "${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa73-cortexa53"
+TUNE_FEATURES_tune-cortexa73-cortexa53 = "aarch64 crc cortexa73-cortexa53"
+TUNE_FEATURES_tune-cortexa73-cortexa53-crypto = "aarch64 crc crypto cortexa73-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa73-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa73-cortexa53 cortexa73-cortexa53-crypto"
BASE_LIB_tune-cortexa73-cortexa53 = "lib64"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (5 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 07/10] aarch64: Adjust big.LITTLE tune files to use -mcpu Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 17:37 ` [OE-core] " Martin Jansa
2020-05-21 16:15 ` [dunfell][ 09/10] gcc: Do not set -march for arm64 for libatomic Khem Raj
` (2 subsequent siblings)
9 siblings, 1 reply; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
Now that they uses -mcpu, its better to have tune specific build
directories, since aarch64 wont be appropriate any longer
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/conf/machine/include/tune-cortexa53.inc | 4 ++++
meta/conf/machine/include/tune-cortexa55.inc | 1 +
meta/conf/machine/include/tune-cortexa57-cortexa53.inc | 1 +
meta/conf/machine/include/tune-cortexa57.inc | 2 ++
meta/conf/machine/include/tune-cortexa72-cortexa53.inc | 2 ++
meta/conf/machine/include/tune-cortexa72.inc | 1 +
meta/conf/machine/include/tune-cortexa73-cortexa53.inc | 2 ++
7 files changed, 13 insertions(+)
diff --git a/meta/conf/machine/include/tune-cortexa53.inc b/meta/conf/machine/include/tune-cortexa53.inc
index 6c0b443eaf..b7327d00c4 100644
--- a/meta/conf/machine/include/tune-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa53.inc
@@ -13,5 +13,9 @@ TUNE_FEATURES_tune-cortexa53 = "aarch64 cortexa53 crc"
TUNE_FEATURES_tune-cortexa53-crypto = "aarch64 cortexa53 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa53 cortexa53-crypto"
+
+TUNE_PKGARCH_tune-cortexa53 = "cortexa53"
+TUNE_PKGARCH_tune-cortexa53-crypto = "cortexa53-crypto"
+
BASE_LIB_tune-cortexa53 = "lib64"
BASE_LIB_tune-cortexa53-crypto = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa55.inc b/meta/conf/machine/include/tune-cortexa55.inc
index 89032b59ec..274944819e 100644
--- a/meta/conf/machine/include/tune-cortexa55.inc
+++ b/meta/conf/machine/include/tune-cortexa55.inc
@@ -9,5 +9,6 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa55"
ARMPKGARCH_tune-cortexa55 = "cortexa55"
TUNE_FEATURES_tune-cortexa55 = "aarch64 cortexa55 crc crypto"
+TUNE_PKGARCH_tune-cortexa55 = "cortexa55"
PACKAGE_EXTRA_ARCHS_tune-cortexa55 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55"
BASE_LIB_tune-cortexa55 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
index ba4b073852..b95d63e86b 100644
--- a/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa57-cortexa53.inc
@@ -11,5 +11,6 @@ require conf/machine/include/arm/arch-armv8a.inc
AVAILTUNES += "cortexa57-cortexa53"
ARMPKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
TUNE_FEATURES_tune-cortexa57-cortexa53 = "aarch64 cortexa57-cortexa53"
+TUNE_PKGARCH_tune-cortexa57-cortexa53 = "cortexa57-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa57-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-aarch64} cortexa57-cortexa53"
BASE_LIB_tune-cortexa57-cortexa53 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa57.inc b/meta/conf/machine/include/tune-cortexa57.inc
index 645a5a7ef6..e8ddeb5786 100644
--- a/meta/conf/machine/include/tune-cortexa57.inc
+++ b/meta/conf/machine/include/tune-cortexa57.inc
@@ -13,5 +13,7 @@ TUNE_FEATURES_tune-cortexa57 = "aarch64 cortexa57 crc"
TUNE_FEATURES_tune-cortexa57-crypto = "aarch64 cortexa57 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa57 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa57"
PACKAGE_EXTRA_ARCHS_tune-cortexa57-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa57 cortexa57-crypto"
+TUNE_PKGARCH_tune-cortexa57 = "cortexa57"
+TUNE_PKGARCH_tune-cortexa57-crypto = "cortexa57-crypto"
BASE_LIB_tune-cortexa57 = "lib64"
BASE_LIB_tune-cortexa57-crypto = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
index 5c54aa33ea..fd1ffeb177 100644
--- a/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa72-cortexa53.inc
@@ -15,6 +15,8 @@ TUNE_FEATURES_tune-cortexa72-cortexa53 = "aarch64 crc cortexa72-co
TUNE_FEATURES_tune-cortexa72-cortexa53-crypto = "aarch64 crc crypto cortexa72-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa72-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72-cortexa53 cortexa72-cortexa53-crypto"
+TUNE_PKGARCH_tune-cortexa72-cortexa53 = "cortexa72-cortexa53"
+TUNE_PKGARCH_tune-cortexa72-cortexa53-crypto = "cortexa72-cortexa53-crypto"
BASE_LIB_tune-cortexa72-cortexa53 = "lib64"
BASE_LIB_tune-cortexa72-cortexa53-crypto = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa72.inc b/meta/conf/machine/include/tune-cortexa72.inc
index 00f7745a22..23640d5c1f 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -10,4 +10,5 @@ AVAILTUNES += "cortexa72"
ARMPKGARCH_tune-cortexa72 = "cortexa72"
TUNE_FEATURES_tune-cortexa72 = "aarch64 cortexa72 crc crypto"
PACKAGE_EXTRA_ARCHS_tune-cortexa72 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
+TUNE_PKGARCH_tune-cortexa72 = "cortexa72"
BASE_LIB_tune-cortexa72 = "lib64"
diff --git a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
index 431d244fe2..ab87c88747 100644
--- a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
+++ b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
@@ -15,6 +15,8 @@ TUNE_FEATURES_tune-cortexa73-cortexa53 = "aarch64 crc cortexa73-co
TUNE_FEATURES_tune-cortexa73-cortexa53-crypto = "aarch64 crc crypto cortexa73-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa73-cortexa53"
PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa73-cortexa53 cortexa73-cortexa53-crypto"
+TUNE_PKGARCH_tune-cortexa73-cortexa53 = "cortexa73-cortexa53"
+TUNE_PKGARCH_tune-cortexa73-cortexa53-crypto = "cortexa73-cortexa53-crypto"
BASE_LIB_tune-cortexa73-cortexa53 = "lib64"
BASE_LIB_tune-cortexa73-cortexa53-crypto = "lib64"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 09/10] gcc: Do not set -march for arm64 for libatomic
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (6 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 10/10] cve-check: Run it after do_fetch Khem Raj
2020-06-03 23:31 ` [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj, Richard Purdie
libatomic has mind of its own when it comes to setting -march for arm64
which conflicts with -mcpu option we pass from environment in some cases
since we always pass -march/-mcpu in OE, its safe to remove this option
mcpu removal from cortex-a55 is no longer needed since the option
conflict is now removed from libatomic instead
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/recipes-devtools/gcc/gcc-9.3.inc | 1 +
...omic-Do-not-enforce-march-on-aarch64.patch | 42 +++++++++++++++++++
meta/recipes-devtools/gcc/gcc-runtime.inc | 4 --
3 files changed, 43 insertions(+), 4 deletions(-)
create mode 100644 meta/recipes-devtools/gcc/gcc-9.3/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
diff --git a/meta/recipes-devtools/gcc/gcc-9.3.inc b/meta/recipes-devtools/gcc/gcc-9.3.inc
index b0411078d3..c9eab911d3 100644
--- a/meta/recipes-devtools/gcc/gcc-9.3.inc
+++ b/meta/recipes-devtools/gcc/gcc-9.3.inc
@@ -67,6 +67,7 @@ SRC_URI = "\
file://0037-CVE-2019-14250-Check-zero-value-in-simple_object_elf.patch \
file://0038-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch \
file://0039-process_alt_operands-Don-t-match-user-defined-regs-o.patch \
+ file://0039-libatomic-Do-not-enforce-march-on-aarch64.patch \
"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/gcc-${PV}"
SRC_URI[sha256sum] = "71e197867611f6054aa1119b13a0c0abac12834765fe2d81f35ac57f84f742d1"
diff --git a/meta/recipes-devtools/gcc/gcc-9.3/0039-libatomic-Do-not-enforce-march-on-aarch64.patch b/meta/recipes-devtools/gcc/gcc-9.3/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
new file mode 100644
index 0000000000..fecb562f51
--- /dev/null
+++ b/meta/recipes-devtools/gcc/gcc-9.3/0039-libatomic-Do-not-enforce-march-on-aarch64.patch
@@ -0,0 +1,42 @@
+From 411fc85c14bb14b07c0db807c55d25ce3f3e507f Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Wed, 13 May 2020 15:10:38 -0700
+Subject: [PATCH] libatomic: Do not enforce march on aarch64
+
+OE passes the right options via gcc compiler cmdline via TUNE_CCARGS
+this can conflict between -mcpu settings and -march setting here, since
+-mcpu will translate into an appropriate -march, lets depend on that
+instead of setting it explicitly
+
+Upstream-Status: Inappropriate [OE-Specific]
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ libatomic/Makefile.am | 1 -
+ libatomic/Makefile.in | 1 -
+ 2 files changed, 2 deletions(-)
+
+diff --git a/libatomic/Makefile.am b/libatomic/Makefile.am
+index 133fbbca77e..ac1ca645876 100644
+--- a/libatomic/Makefile.am
++++ b/libatomic/Makefile.am
+@@ -125,7 +125,6 @@ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix _$(s)_.lo,$(SIZEOBJS)))
+ ## On a target-specific basis, include alternates to be selected by IFUNC.
+ if HAVE_IFUNC
+ if ARCH_AARCH64_LINUX
+-IFUNC_OPTIONS = -march=armv8-a+lse
+ libatomic_la_LIBADD += $(foreach s,$(SIZES),$(addsuffix _$(s)_1_.lo,$(SIZEOBJS)))
+ endif
+ if ARCH_ARM_LINUX
+diff --git a/libatomic/Makefile.in b/libatomic/Makefile.in
+index a51807e95c9..97df2d7ff03 100644
+--- a/libatomic/Makefile.in
++++ b/libatomic/Makefile.in
+@@ -431,7 +431,6 @@ M_SRC = $(firstword $(filter %/$(M_FILE), $(all_c_files)))
+ libatomic_la_LIBADD = $(foreach s,$(SIZES),$(addsuffix \
+ _$(s)_.lo,$(SIZEOBJS))) $(am__append_1) $(am__append_2) \
+ $(am__append_3) $(am__append_4)
+-@ARCH_AARCH64_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv8-a+lse
+ @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a+fp -DHAVE_KERNEL64
+ @ARCH_I386_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=i586
+ @ARCH_X86_64_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -mcx16
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc
index d9a4e483cc..ace706dbf4 100644
--- a/meta/recipes-devtools/gcc/gcc-runtime.inc
+++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
@@ -18,10 +18,6 @@ EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
EXTRA_OECONF_append = " --cache-file=${B}/config.cache"
EXTRA_OECONF_append_libc-newlib = " --with-newlib"
-# cortex-a55 is ARMv8.2-a based but libatomic explicitly asks for -march=armv8.1-a
-# which caused -march conflicts in gcc
-TUNE_CCARGS_remove = "-mcpu=cortex-a55+crc -mcpu=cortex-a55 -mcpu=cortex-a55+crc+crypto"
-
# Disable ifuncs for libatomic on arm conflicts -march/-mcpu
EXTRA_OECONF_append_arm = " libat_cv_have_ifunc=no "
EXTRA_OECONF_append_armeb = " libat_cv_have_ifunc=no "
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [dunfell][ 10/10] cve-check: Run it after do_fetch
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (7 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 09/10] gcc: Do not set -march for arm64 for libatomic Khem Raj
@ 2020-05-21 16:15 ` Khem Raj
2020-06-03 23:31 ` [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-05-21 16:15 UTC (permalink / raw)
To: openembedded-core; +Cc: Khem Raj
Certain recipes e.g. bash readline ( from meta-gplv2 ) download patches instead of having them in
metadata, this could fail cve_check
ERROR: readline-5.2-r9 do_cve_check: File Not found: qemuarm/build/../downloads/readline52-001
This patch ensures that download is done before running CVE scan, even
though these will be external patches and may not contain CVE tags as it
expects, but it will fix the run failures as seen above
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/classes/cve-check.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 2a530a0489..556ac6e67f 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -65,7 +65,7 @@ python do_cve_check () {
}
-addtask cve_check before do_build
+addtask cve_check before do_build after do_fetch
do_cve_check[depends] = "cve-update-db-native:do_populate_cve_db"
do_cve_check[nostamp] = "1"
--
2.26.2
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-21 16:15 ` [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH Khem Raj
@ 2020-05-21 17:37 ` Martin Jansa
2020-05-21 23:49 ` Anuj Mittal
0 siblings, 1 reply; 18+ messages in thread
From: Martin Jansa @ 2020-05-21 17:37 UTC (permalink / raw)
To: Khem Raj; +Cc: Patches and discussions about the oe-core layer, Richard Purdie
[-- Attachment #1: Type: text/plain, Size: 687 bytes --]
On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com> wrote:
> Now that they uses -mcpu, its better to have tune specific build
> directories, since aarch64 wont be appropriate any longer
>
I agree with Steve that this is a bit invasive for stable branch, but on
the other hand it's long overdue and if we don't improve it in LTS branch
then many people will need to carry local work arounds for multi-machine
builds. +1 from me.
Once the LAYERVERSION_core is bumped because of those python modules, then
BSPs will also be able to depend on newer version of oe-core when they
start using one of new tune files.
Acked-by: Martin Jansa <Martin.Jansa@gmail.com>
[-- Attachment #2: Type: text/html, Size: 1063 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-21 17:37 ` [OE-core] " Martin Jansa
@ 2020-05-21 23:49 ` Anuj Mittal
2020-05-22 0:05 ` Khem Raj
0 siblings, 1 reply; 18+ messages in thread
From: Anuj Mittal @ 2020-05-21 23:49 UTC (permalink / raw)
To: raj.khem, Martin.Jansa; +Cc: openembedded-core, richard.purdie
On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com> wrote:
> > Now that they uses -mcpu, its better to have tune specific build
> > directories, since aarch64 wont be appropriate any longer
>
> I agree with Steve that this is a bit invasive for stable branch, but
> on the other hand it's long overdue and if we don't improve it in LTS
> branch then many people will need to carry local work arounds for
> multi-machine builds. +1 from me.
>
But this is against the LTS/Stable branch policy. What is the point of
having a policy if we are going to keep making exceptions? There'd be
other changes as well for which people might be carrying work-arounds.
Would we be willing to make exceptions for all?
Thanks,
Anuj
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-21 23:49 ` Anuj Mittal
@ 2020-05-22 0:05 ` Khem Raj
2020-05-22 0:23 ` Anuj Mittal
0 siblings, 1 reply; 18+ messages in thread
From: Khem Raj @ 2020-05-22 0:05 UTC (permalink / raw)
To: Mittal, Anuj; +Cc: Martin.Jansa, openembedded-core, richard.purdie
On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mittal@intel.com> wrote:
>
> On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com> wrote:
> > > Now that they uses -mcpu, its better to have tune specific build
> > > directories, since aarch64 wont be appropriate any longer
> >
> > I agree with Steve that this is a bit invasive for stable branch, but
> > on the other hand it's long overdue and if we don't improve it in LTS
> > branch then many people will need to carry local work arounds for
> > multi-machine builds. +1 from me.
> >
>
> But this is against the LTS/Stable branch policy. What is the point of
> having a policy if we are going to keep making exceptions? There'd be
> other changes as well for which people might be carrying work-arounds.
> Would we be willing to make exceptions for all?
>
Thanks for bringing this up. Policy exceptions are not common but they
are not absent either
hence context is important for such changes, I am definitely interested to hear
about how it is going to affect arm64 users at this early stage of
release. if someone
is broken due to these changes that should be addressed.
> Thanks,
>
> Anuj
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-22 0:05 ` Khem Raj
@ 2020-05-22 0:23 ` Anuj Mittal
2020-06-04 8:30 ` Richard Purdie
2020-06-04 23:47 ` Khem Raj
0 siblings, 2 replies; 18+ messages in thread
From: Anuj Mittal @ 2020-05-22 0:23 UTC (permalink / raw)
To: raj.khem; +Cc: openembedded-core, richard.purdie, Martin.Jansa
On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mittal@intel.com>
> wrote:
> > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com>
> > > wrote:
> > > > Now that they uses -mcpu, its better to have tune specific
> > > > build
> > > > directories, since aarch64 wont be appropriate any longer
> > >
> > > I agree with Steve that this is a bit invasive for stable branch,
> > > but
> > > on the other hand it's long overdue and if we don't improve it in
> > > LTS
> > > branch then many people will need to carry local work arounds for
> > > multi-machine builds. +1 from me.
> > >
> >
> > But this is against the LTS/Stable branch policy. What is the point
> > of
> > having a policy if we are going to keep making exceptions? There'd
> > be
> > other changes as well for which people might be carrying work-
> > arounds.
> > Would we be willing to make exceptions for all?
> >
>
> Thanks for bringing this up. Policy exceptions are not common but
> they
That's two exceptions in a week.
I am not against the change but I think the policy document should be
modified to define how exceptions should/will be handled.
> are not absent either
> hence context is important for such changes, I am definitely
> interested to hear
> about how it is going to affect arm64 users at this early stage of
> release.
The release has been made and I think the branch is assumed to be
stable from the time it was released and policy should be applied?
There's no early release stage defined where-in such changes would be
acceptable.
Thanks,
Anuj
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
` (8 preceding siblings ...)
2020-05-21 16:15 ` [dunfell][ 10/10] cve-check: Run it after do_fetch Khem Raj
@ 2020-06-03 23:31 ` Khem Raj
9 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-06-03 23:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer; +Cc: Richard Purdie
Ping for this series.
On Thu, May 21, 2020 at 9:15 AM Khem Raj <raj.khem@gmail.com> wrote:
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
> meta/conf/machine/include/tune-cortexa55.inc | 17 ++++++++++++++
> .../include/tune-cortexa73-cortexa53.inc | 23 +++++++++++++++++++
> 2 files changed, 40 insertions(+)
> create mode 100644 meta/conf/machine/include/tune-cortexa55.inc
> create mode 100644 meta/conf/machine/include/tune-cortexa73-cortexa53.inc
>
> diff --git a/meta/conf/machine/include/tune-cortexa55.inc b/meta/conf/machine/include/tune-cortexa55.inc
> new file mode 100644
> index 0000000000..8242cc9cef
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-cortexa55.inc
> @@ -0,0 +1,17 @@
> +DEFAULTTUNE ?= "cortexa55"
> +
> +TUNEVALID[cortexa55] = "Enable Cortex-A55 specific processor optimizations"
> +TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa55', ' -mcpu=cortex-a55', '', d)}"
> +
> +require conf/machine/include/arm/arch-armv8a.inc
> +
> +# Little Endian base configs
> +AVAILTUNES += "cortexa55 cortexa55-crypto"
> +ARMPKGARCH_tune-cortexa55 = "cortexa55"
> +ARMPKGARCH_tune-cortexa55-crypto = "cortexa55"
> +TUNE_FEATURES_tune-cortexa55 = "aarch64 cortexa55 crc"
> +TUNE_FEATURES_tune-cortexa55-crypto = "aarch64 cortexa55 crc crypto"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa55 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa55"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa55-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa55 cortexa55-crypto"
> +BASE_LIB_tune-cortexa55 = "lib64"
> +BASE_LIB_tune-cortexa55-crypto = "lib64"
> diff --git a/meta/conf/machine/include/tune-cortexa73-cortexa53.inc b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
> new file mode 100644
> index 0000000000..8df418227f
> --- /dev/null
> +++ b/meta/conf/machine/include/tune-cortexa73-cortexa53.inc
> @@ -0,0 +1,23 @@
> +DEFAULTTUNE ?= "cortexa73-cortexa53"
> +
> +require conf/machine/include/arm/arch-armv8a.inc
> +
> +TUNEVALID[cortexa73-cortexa53] = "Enable big.LITTLE Cortex-A73.Cortex-A53 specific processor optimizations"
> +
> +TUNECONFLICTS[aarch64] = "armv4 armv5 armv6 armv7 armv7a"
> +
> +MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", "cortexa73-cortexa53:", "" ,d)}"
> +
> +TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa73-cortexa53", " -mtune=cortex-a73.cortex-a53", "", d)}"
> +
> +# cortexa73.cortexa53 implies crc support
> +AVAILTUNES += "cortexa73-cortexa53 cortexa73-cortexa53-crypto"
> +ARMPKGARCH_tune-cortexa73-cortexa53 = "cortexa73-cortexa53"
> +ARMPKGARCH_tune-cortexa73-cortexa53-crypto = "cortexa73-cortexa53"
> +TUNE_FEATURES_tune-cortexa73-cortexa53 = "${TUNE_FEATURES_tune-armv8a-crc} cortexa73-cortexa53"
> +TUNE_FEATURES_tune-cortexa73-cortexa53-crypto = "${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa73-cortexa53"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53 = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa73-cortexa53"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa73-cortexa53-crypto = "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa73-cortexa53 cortexa73-cortexa53-crypto"
> +BASE_LIB_tune-cortexa73-cortexa53 = "lib64"
> +BASE_LIB_tune-cortexa73-cortexa53-crypto = "lib64"
> +
> --
> 2.26.2
>
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-22 0:23 ` Anuj Mittal
@ 2020-06-04 8:30 ` Richard Purdie
2020-06-05 0:04 ` Khem Raj
2020-06-04 23:47 ` Khem Raj
1 sibling, 1 reply; 18+ messages in thread
From: Richard Purdie @ 2020-06-04 8:30 UTC (permalink / raw)
To: Mittal, Anuj, raj.khem; +Cc: openembedded-core, Martin.Jansa
On Fri, 2020-05-22 at 00:23 +0000, Mittal, Anuj wrote:
> On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mittal@intel.com
> > >
> > wrote:
> > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com>
> > > > wrote:
> > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > build
> > > > > directories, since aarch64 wont be appropriate any longer
> > > >
> > > > I agree with Steve that this is a bit invasive for stable
> > > > branch,
> > > > but
> > > > on the other hand it's long overdue and if we don't improve it
> > > > in
> > > > LTS
> > > > branch then many people will need to carry local work arounds
> > > > for
> > > > multi-machine builds. +1 from me.
> > > >
> > >
> > > But this is against the LTS/Stable branch policy. What is the
> > > point
> > > of
> > > having a policy if we are going to keep making exceptions?
> > > There'd
> > > be
> > > other changes as well for which people might be carrying work-
> > > arounds.
> > > Would we be willing to make exceptions for all?
> > >
> >
> > Thanks for bringing this up. Policy exceptions are not common but
> > they
>
> That's two exceptions in a week.
>
> I am not against the change but I think the policy document should be
> modified to define how exceptions should/will be handled.
>
> > are not absent either
> > hence context is important for such changes, I am definitely
> > interested to hear
> > about how it is going to affect arm64 users at this early stage of
> > release.
>
> The release has been made and I think the branch is assumed to be
> stable from the time it was released and policy should be applied?
> There's no early release stage defined where-in such changes would be
> acceptable.
This series doesn't have a decision on it yet. If an exception were
made, it would be two exceptions in the lifetime of the LTS so far, not
just a week. The fact we'd like to make a point release is focusing the
fact we need to make some decisions rather than a sudden stream of
policy exceptions.
I'd also note its most likely we'd find issues just after release as
people start using things, over time it becomes much less likely.
If such issues are identified, particularly now as people start using
it, the question is what we do about it. If we can fix things to
improve things for users and the risk is either low, or managed to a
specific subset of users who can benefit, that does seem like a
sensible thing to do.
I guess I'd hoped we could all be sensible about these things, the LTS
policy is there as a set of 'guide rails' to make decisions against but
as a maintainer, I know that not everything that makes sense neatly
fits within a written set of rules. The LTS maintainer does need to
have some ability to make decisions and I've always thought it was
clear the TSCs are the ultimate decision makers for any technical
decision the project faces should there not be consensus.
In the case of these patches I'm not seeing anyone arguing against them
on technical grounds or saying they don't make sense other than some
things I've said to Steve! The complaint is that they break policy.
I will discuss making a escalation and final decision path clearer with
the YP TSC (who wrote/maintain the policy).
Cheers,
Richard
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-05-22 0:23 ` Anuj Mittal
2020-06-04 8:30 ` Richard Purdie
@ 2020-06-04 23:47 ` Khem Raj
1 sibling, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-06-04 23:47 UTC (permalink / raw)
To: Mittal, Anuj; +Cc: openembedded-core, richard.purdie, Martin.Jansa
On Thu, May 21, 2020 at 5:23 PM Mittal, Anuj <anuj.mittal@intel.com> wrote:
>
> On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mittal@intel.com>
> > wrote:
> > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com>
> > > > wrote:
> > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > build
> > > > > directories, since aarch64 wont be appropriate any longer
> > > >
> > > > I agree with Steve that this is a bit invasive for stable branch,
> > > > but
> > > > on the other hand it's long overdue and if we don't improve it in
> > > > LTS
> > > > branch then many people will need to carry local work arounds for
> > > > multi-machine builds. +1 from me.
> > > >
> > >
> > > But this is against the LTS/Stable branch policy. What is the point
> > > of
> > > having a policy if we are going to keep making exceptions? There'd
> > > be
> > > other changes as well for which people might be carrying work-
> > > arounds.
> > > Would we be willing to make exceptions for all?
> > >
> >
> > Thanks for bringing this up. Policy exceptions are not common but
> > they
>
> That's two exceptions in a week.
>
> I am not against the change but I think the policy document should be
> modified to define how exceptions should/will be handled.
>
> > are not absent either
> > hence context is important for such changes, I am definitely
> > interested to hear
> > about how it is going to affect arm64 users at this early stage of
> > release.
>
> The release has been made and I think the branch is assumed to be
> stable from the time it was released and policy should be applied?
> There's no early release stage defined where-in such changes would be
> acceptable.
we do have QA qualification criteria for releases and LTS is no different for
meeting that requirement. so these patches if regressing should be
found out before
point release.
LTS has to be useful for new SOCs and with the least amount of
patching, I am yet
to hear technical downsides or concerns for this patchset. I have no problem
in maintaining them in the downstream distro since they are already in master it
really is fine since they will be in the next LTS and we will be fine.
I was hoping the
experience better for others and have a bit of fewer patches to maintain.
>
> Thanks,
>
> Anuj
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core] [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH
2020-06-04 8:30 ` Richard Purdie
@ 2020-06-05 0:04 ` Khem Raj
0 siblings, 0 replies; 18+ messages in thread
From: Khem Raj @ 2020-06-05 0:04 UTC (permalink / raw)
To: Richard Purdie; +Cc: Mittal, Anuj, openembedded-core, Martin.Jansa
On Thu, Jun 4, 2020 at 1:30 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Fri, 2020-05-22 at 00:23 +0000, Mittal, Anuj wrote:
> > On Thu, 2020-05-21 at 17:05 -0700, Khem Raj wrote:
> > > On Thu, May 21, 2020 at 4:49 PM Mittal, Anuj <anuj.mittal@intel.com
> > > >
> > > wrote:
> > > > On Thu, 2020-05-21 at 19:37 +0200, Martin Jansa wrote:
> > > > > On Thu, May 21, 2020 at 6:16 PM Khem Raj <raj.khem@gmail.com>
> > > > > wrote:
> > > > > > Now that they uses -mcpu, its better to have tune specific
> > > > > > build
> > > > > > directories, since aarch64 wont be appropriate any longer
> > > > >
> > > > > I agree with Steve that this is a bit invasive for stable
> > > > > branch,
> > > > > but
> > > > > on the other hand it's long overdue and if we don't improve it
> > > > > in
> > > > > LTS
> > > > > branch then many people will need to carry local work arounds
> > > > > for
> > > > > multi-machine builds. +1 from me.
> > > > >
> > > >
> > > > But this is against the LTS/Stable branch policy. What is the
> > > > point
> > > > of
> > > > having a policy if we are going to keep making exceptions?
> > > > There'd
> > > > be
> > > > other changes as well for which people might be carrying work-
> > > > arounds.
> > > > Would we be willing to make exceptions for all?
> > > >
> > >
> > > Thanks for bringing this up. Policy exceptions are not common but
> > > they
> >
> > That's two exceptions in a week.
> >
> > I am not against the change but I think the policy document should be
> > modified to define how exceptions should/will be handled.
> >
> > > are not absent either
> > > hence context is important for such changes, I am definitely
> > > interested to hear
> > > about how it is going to affect arm64 users at this early stage of
> > > release.
> >
> > The release has been made and I think the branch is assumed to be
> > stable from the time it was released and policy should be applied?
> > There's no early release stage defined where-in such changes would be
> > acceptable.
>
> This series doesn't have a decision on it yet. If an exception were
> made, it would be two exceptions in the lifetime of the LTS so far, not
> just a week. The fact we'd like to make a point release is focusing the
> fact we need to make some decisions rather than a sudden stream of
> policy exceptions.
>
> I'd also note its most likely we'd find issues just after release as
> people start using things, over time it becomes much less likely.
>
> If such issues are identified, particularly now as people start using
> it, the question is what we do about it. If we can fix things to
> improve things for users and the risk is either low, or managed to a
> specific subset of users who can benefit, that does seem like a
> sensible thing to do.
>
> I guess I'd hoped we could all be sensible about these things, the LTS
> policy is there as a set of 'guide rails' to make decisions against but
> as a maintainer, I know that not everything that makes sense neatly
> fits within a written set of rules. The LTS maintainer does need to
> have some ability to make decisions and I've always thought it was
> clear the TSCs are the ultimate decision makers for any technical
> decision the project faces should there not be consensus.
downstream distros will require such things for supporting their products,
in past it was done on their chosen release and they stayed with that
release with their own delta, the hope is that they will use LTS and just from
LTS to LTS in product cycles. IMO LTS will have to considerate to
this fact, if we do not want downstream distros to diverge significantly
and if we want to put hard conditions early on release then I guess
users will have to devise their own plans regardless of LTS.
e.g. See the delta between ubuntu
LTS first point release ( 20.04 and 20.04.1 ), most users wait for first point
release to migrate to next LTS there is a reason for that.
There is quite a bit of stabilization that happens
early on in LTS life.
>
> In the case of these patches I'm not seeing anyone arguing against them
> on technical grounds or saying they don't make sense other than some
> things I've said to Steve! The complaint is that they break policy.
>
> I will discuss making a escalation and final decision path clearer with
> the YP TSC (who wrote/maintain the policy).
>
> Cheers,
>
> Richard
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-06-05 0:05 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-21 16:15 [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
2020-05-21 16:15 ` [dunfell][ 02/10] gcc-runtime: Avoid march conflicts with newer cortex-a55 CPUs Khem Raj
2020-05-21 16:15 ` [dunfell][ 03/10] glibc: Update to latest on 2.31 branch Khem Raj
2020-05-21 16:15 ` [dunfell][ 04/10] wayland: fix condition for strndup detection Khem Raj
2020-05-21 16:15 ` [dunfell][ 05/10] tune-cortexa55.inc: crc and crypto extentions are default on cortex-a55 Khem Raj
2020-05-21 16:15 ` [dunfell][ 06/10] tune-cortexa57.inc: Add new tune file Khem Raj
2020-05-21 16:15 ` [dunfell][ 07/10] aarch64: Adjust big.LITTLE tune files to use -mcpu Khem Raj
2020-05-21 16:15 ` [dunfell][ 08/10] armv8/tunes: Define TUNE_PKGARCH Khem Raj
2020-05-21 17:37 ` [OE-core] " Martin Jansa
2020-05-21 23:49 ` Anuj Mittal
2020-05-22 0:05 ` Khem Raj
2020-05-22 0:23 ` Anuj Mittal
2020-06-04 8:30 ` Richard Purdie
2020-06-05 0:04 ` Khem Raj
2020-06-04 23:47 ` Khem Raj
2020-05-21 16:15 ` [dunfell][ 09/10] gcc: Do not set -march for arm64 for libatomic Khem Raj
2020-05-21 16:15 ` [dunfell][ 10/10] cve-check: Run it after do_fetch Khem Raj
2020-06-03 23:31 ` [dunfell][ 01/10] tunes: Add new tune files for cortexa55 and cortexa73-cortexa53 Khem Raj
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.