* [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
@ 2011-07-29 14:59 Khem Raj
2011-07-29 16:39 ` Martin Jansa
0 siblings, 1 reply; 9+ messages in thread
From: Khem Raj @ 2011-07-29 14:59 UTC (permalink / raw)
To: openembedded-core
Currently when using thumb feature all recipes can not be compiled in
thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
set even when thumb was global choice. With this patch we remove thumb
from tune features for these recipes. This will make sure that compiler
is not using thumb options to compile these recipes at all.
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
meta/classes/qt4e.bbclass | 2 +-
meta/classes/qt4x11.bbclass | 2 +-
meta/conf/machine/include/tune-thumb.inc | 32 --------------------
meta/recipes-core/eglibc/eglibc.inc | 4 +-
meta/recipes-core/glib-2.0/glib.inc | 4 ++-
meta/recipes-core/glibc/glibc.inc | 4 ++-
meta/recipes-core/glibc/glibc_2.10.1.bb | 3 +-
meta/recipes-core/uclibc/uclibc.inc | 2 +-
meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc | 3 +-
.../xorg-xserver/xserver-kdrive.inc | 4 ++-
meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb | 3 +-
.../gstreamer/gst-plugins-bad_0.10.21.bb | 3 +-
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb | 4 ++-
meta/recipes-multimedia/tremor/tremor_20101121.bb | 4 ++-
meta/recipes-qt/qt4/qt4_arch.inc | 3 +-
meta/recipes-support/boost/boost-36.inc | 4 ++-
meta/recipes-support/gmp/gmp.inc | 3 +-
meta/recipes-support/libgcrypt/libgcrypt.inc | 3 +-
meta/recipes-support/liboil/liboil_0.3.17.bb | 3 +-
19 files changed, 39 insertions(+), 51 deletions(-)
delete mode 100644 meta/conf/machine/include/tune-thumb.inc
diff --git a/meta/classes/qt4e.bbclass b/meta/classes/qt4e.bbclass
index 670605b..ab91ab3 100644
--- a/meta/classes/qt4e.bbclass
+++ b/meta/classes/qt4e.bbclass
@@ -15,4 +15,4 @@ export OE_QMAKE_EXTRA_MODULES = "network"
EXTRA_QMAKEVARS_PRE += " QT_LIBINFIX=${QT_LIBINFIX} "
# Qt4 uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
diff --git a/meta/classes/qt4x11.bbclass b/meta/classes/qt4x11.bbclass
index abb1d9d..3704b48 100644
--- a/meta/classes/qt4x11.bbclass
+++ b/meta/classes/qt4x11.bbclass
@@ -6,4 +6,4 @@ QT_DIR_NAME = "qt4"
QT_LIBINFIX = ""
# Qt4 uses atomic instructions not supported in thumb mode
-ARM_INSTRUCTION_SET = "arm"
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
diff --git a/meta/conf/machine/include/tune-thumb.inc b/meta/conf/machine/include/tune-thumb.inc
deleted file mode 100644
index 9f6ce95..0000000
--- a/meta/conf/machine/include/tune-thumb.inc
+++ /dev/null
@@ -1,32 +0,0 @@
-#tune file for thumb instructions
-
-ARM_INSTRUCTION_SET ?= "arm"
-# "arm" "thumb"
-# The instruction set the compiler should use when generating application
-# code. The kernel is always compiled with arm code at present. arm code
-# is the original 32 bit ARM instruction set, thumb code is the 16 bit
-# encoded RISC sub-set. Thumb code is smaller (maybe 70% of the ARM size)
-# but requires more instructions (140% for 70% smaller code) so may be
-# slower.
-
-THUMB_INTERWORK ?= "yes"
-# "yes" "no"
-# Whether to compile with code to allow interworking between the two
-# instruction sets. This allows thumb code to be executed on a primarily
-# arm system and vice versa. It is strongly recommended that DISTROs not
-# turn this off - the actual cost is very small.
-
-OVERRIDE_THUMB = "${@['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
-OVERRIDE_INTERWORK = "${@['', ':thumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}"
-OVERRIDES .= "${OVERRIDE_THUMB}${OVERRIDE_INTERWORK}"
-
-# Compiler and linker options for application code and kernel code. These
-# options ensure that the compiler has the correct settings for the selected
-# instruction set and interworking.
-ARM_INTERWORK_M_OPT = "${@['-mno-thumb-interwork', '-mthumb-interwork'][bb.data.getVar('THUMB_INTERWORK', d, 1) == 'yes']}"
-ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
-
-#
-TUNE_CCARGS += "${ARM_INTERWORK_M_OPT} ${ARM_THUMB_M_OPT}"
-TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
-
diff --git a/meta/recipes-core/eglibc/eglibc.inc b/meta/recipes-core/eglibc/eglibc.inc
index 1b2e630..2adcd05 100644
--- a/meta/recipes-core/eglibc/eglibc.inc
+++ b/meta/recipes-core/eglibc/eglibc.inc
@@ -33,8 +33,6 @@ LEAD_SONAME = "libc.so"
GLIBC_EXTRA_OECONF ?= ""
INHIBIT_DEFAULT_DEPS = "1"
-ARM_INSTRUCTION_SET = "arm"
-
# eglibc uses PARALLELMFLAGS variable to pass parallel build info so transfer
# PARALLEL_MAKE into PARALLELMFLAGS and empty out PARALLEL_MAKE
EGLIBCPARALLELISM := "PARALLELMFLAGS="${PARALLEL_MAKE}""
@@ -48,3 +46,5 @@ do_configure_prepend() {
sed -e "s#@BASH@#/bin/sh#" -i ${S}/elf/ldd.bash.in
echo '${OE_FEATURES}' > ${B}/option-groups.config
}
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index e25db3d..f7e88e3 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -33,5 +33,7 @@ FILES_${PN} = "${libdir}/lib*${SOLIBS} ${sysconfdir}/bash_completion.d ${datadir
FILES_${PN}-dev += "${libdir}/glib-2.0/include"
FILES_${PN}-dbg += "${datadir}/glib-2.0/gdb ${datadir}/gdb"
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
USE_NLS = "yes"
diff --git a/meta/recipes-core/glibc/glibc.inc b/meta/recipes-core/glibc/glibc.inc
index 57d693c..a447a82 100644
--- a/meta/recipes-core/glibc/glibc.inc
+++ b/meta/recipes-core/glibc/glibc.inc
@@ -57,4 +57,6 @@ do_rig_locales() {
addtask rig_locales before do_compile after do_configure
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
diff --git a/meta/recipes-core/glibc/glibc_2.10.1.bb b/meta/recipes-core/glibc/glibc_2.10.1.bb
index e76f3c0..dfb09e0 100644
--- a/meta/recipes-core/glibc/glibc_2.10.1.bb
+++ b/meta/recipes-core/glibc/glibc_2.10.1.bb
@@ -1,6 +1,7 @@
require glibc.inc
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
PACKAGES_DYNAMIC = "libc6*"
RPROVIDES_${PN}-dev = "libc6-dev virtual-libc-dev"
diff --git a/meta/recipes-core/uclibc/uclibc.inc b/meta/recipes-core/uclibc/uclibc.inc
index 222c34f..e6e13af 100644
--- a/meta/recipes-core/uclibc/uclibc.inc
+++ b/meta/recipes-core/uclibc/uclibc.inc
@@ -125,7 +125,7 @@ configmangle = '/^KERNEL_HEADERS/d; \
/^SHARED_LIB_LOADER_PREFIX/d; \
/^UCLIBC_EXTRA_CFLAGS/d; \
s,.*UCLIBC_HAS_WCHAR.*,UCLIBC_HAS_WCHAR=y,g; \
- ${@["","s,.*COMPILE_IN_THUMB_MODE.*,COMPILE_IN_THUMB_MODE=y,;"][bb.data.getVar("ARM_INSTRUCTION_SET", d, 1) != "arm"]} \
+ ${@bb.utils.contains("TUNE_FEATURES", "thumb", "COMPILE_IN_THUMB_MODE=y", "", d)} \
${@["","s,.*UCLIBC_HAS_LOCALE.*,UCLIBC_HAS_LOCALE=y,;"][bb.data.getVar("USE_NLS", d, 1) == "yes"]} \
${@["","s,.*LDSO_GNU_HASH_SUPPORT.*,# LDSO_GNU_HASH_SUPPORT is not set,;"][bb.data.getVar("TARGET_ARCH", d, 1) in ['mips', 'mipsel', 'mips64', 'mips64el', 'avr32']]} \
/^CROSS/d; \
diff --git a/meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc b/meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc
index cb5b087..ce7c3d1 100644
--- a/meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc
+++ b/meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc
@@ -47,6 +47,7 @@ EXTRA_OECONF_BASE = "--enable-libssp --disable-bootstrap --disable-libgomp --dis
EXTRA_OECONF_INITIAL = "--disable-libmudflap --disable-libgomp --disable-libssp --disable-bootstrap"
EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap --disable-libgomp --disable-libssp --disable-bootstrap"
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
addtask unpack2 after do_unpack before do_patch
diff --git a/meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc b/meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc
index 52b63ed..21758ba 100644
--- a/meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc
+++ b/meta/recipes-graphics/xorg-xserver/xserver-kdrive.inc
@@ -93,7 +93,9 @@ RDEPENDS_xserver-kdrive-via = "${PN}"
inherit autotools pkgconfig
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
EXTRA_OECONF = "--enable-composite --enable-kdrive \
--disable-dga --disable-dri --disable-xinerama \
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb b/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb
index 53f4d29..e36cde4 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb
@@ -12,7 +12,8 @@ BBCLASSEXTEND = "native"
# (not just those with the ARM instruction set), this should be removed,
# (or replaced by a permitted #define).
#FIXME: remove the following
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
PR = "r0"
diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
index 2b8a89c..0219cbc 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-bad_0.10.21.bb
@@ -16,7 +16,8 @@ inherit gettext
EXTRA_OECONF += "--disable-examples --disable-experimental --disable-sdl --disable-cdaudio \
--with-plugins=musicbrainz,wavpack,ivorbis,mpegvideoparse --disable-vdpau --disable-apexsink"
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool 2.2.2
diff --git a/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb b/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
index aec929c..919dc8c 100644
--- a/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
+++ b/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
@@ -31,4 +31,6 @@ do_configure_prepend () {
touch NEWS AUTHORS ChangeLog
}
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
diff --git a/meta/recipes-multimedia/tremor/tremor_20101121.bb b/meta/recipes-multimedia/tremor/tremor_20101121.bb
index 4a4cb28..49fed41 100644
--- a/meta/recipes-multimedia/tremor/tremor_20101121.bb
+++ b/meta/recipes-multimedia/tremor/tremor_20101121.bb
@@ -16,4 +16,6 @@ inherit autotools
EXTRA_OECONF=" --enable-shared --disable-rpath "
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
diff --git a/meta/recipes-qt/qt4/qt4_arch.inc b/meta/recipes-qt/qt4/qt4_arch.inc
index e8c8fab..3d9a0e3 100644
--- a/meta/recipes-qt/qt4/qt4_arch.inc
+++ b/meta/recipes-qt/qt4/qt4_arch.inc
@@ -1,6 +1,7 @@
inherit siteinfo
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
def qt_arch(d):
import bb, re
diff --git a/meta/recipes-support/boost/boost-36.inc b/meta/recipes-support/boost/boost-36.inc
index bb267d7..02a009f 100644
--- a/meta/recipes-support/boost/boost-36.inc
+++ b/meta/recipes-support/boost/boost-36.inc
@@ -10,7 +10,9 @@ DEPENDS = "boost-jam-native zlib"
LICENSE = "Boost"
PR = "r4"
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
+
BOOST_VER = "${@"_".join(bb.data.getVar("PV",d,1).split("."))}"
BOOST_MAJ = "${@"_".join(bb.data.getVar("PV",d,1).split(".")[0:2])}"
BOOST_P = "boost_${BOOST_VER}"
diff --git a/meta/recipes-support/gmp/gmp.inc b/meta/recipes-support/gmp/gmp.inc
index 66349e6..868e36d 100644
--- a/meta/recipes-support/gmp/gmp.inc
+++ b/meta/recipes-support/gmp/gmp.inc
@@ -9,7 +9,8 @@ SRC_URI = "${GNU_MIRROR}/gmp/gmp-${PV}.tar.bz2 \
inherit autotools
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
acpaths = ""
diff --git a/meta/recipes-support/libgcrypt/libgcrypt.inc b/meta/recipes-support/libgcrypt/libgcrypt.inc
index 128aed3..c3a8793 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt.inc
+++ b/meta/recipes-support/libgcrypt/libgcrypt.inc
@@ -23,7 +23,8 @@ do_install_append() {
install -m 0644 ${S}/src/libgcrypt.pc ${D}/${libdir}/pkgconfig/
}
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
# move libgcrypt-config into -dev package
FILES_${PN} = "${libdir}/lib*.so.*"
diff --git a/meta/recipes-support/liboil/liboil_0.3.17.bb b/meta/recipes-support/liboil/liboil_0.3.17.bb
index f342a82..5f03701 100644
--- a/meta/recipes-support/liboil/liboil_0.3.17.bb
+++ b/meta/recipes-support/liboil/liboil_0.3.17.bb
@@ -22,4 +22,5 @@ SRC_URI[sha256sum] = "105f02079b0b50034c759db34b473ecb5704ffa20a5486b60a8b769812
inherit autotools pkgconfig
-ARM_INSTRUCTION_SET = "arm"
+# Remove thumb from tune features since we can not compile this in using thumb mode
+TUNE_FEATURES := "${@oe_filter_out('thumb', '${TUNE_FEATURES}', d)}"
--
1.7.4.1
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
2011-07-29 14:59 [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES Khem Raj
@ 2011-07-29 16:39 ` Martin Jansa
2011-07-29 16:46 ` Khem Raj
2011-07-29 17:04 ` [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET Martin Jansa
0 siblings, 2 replies; 9+ messages in thread
From: Martin Jansa @ 2011-07-29 16:39 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 3374 bytes --]
On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
> Currently when using thumb feature all recipes can not be compiled in
> thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
> set even when thumb was global choice. With this patch we remove thumb
> from tune features for these recipes. This will make sure that compiler
> is not using thumb options to compile these recipes at all.
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
> meta/classes/qt4e.bbclass | 2 +-
> meta/classes/qt4x11.bbclass | 2 +-
> meta/conf/machine/include/tune-thumb.inc | 32 --------------------
> meta/recipes-core/eglibc/eglibc.inc | 4 +-
> meta/recipes-core/glib-2.0/glib.inc | 4 ++-
> meta/recipes-core/glibc/glibc.inc | 4 ++-
> meta/recipes-core/glibc/glibc_2.10.1.bb | 3 +-
> meta/recipes-core/uclibc/uclibc.inc | 2 +-
> meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc | 3 +-
> .../xorg-xserver/xserver-kdrive.inc | 4 ++-
> meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb | 3 +-
> .../gstreamer/gst-plugins-bad_0.10.21.bb | 3 +-
> meta/recipes-multimedia/libmad/libmad_0.15.1b.bb | 4 ++-
> meta/recipes-multimedia/tremor/tremor_20101121.bb | 4 ++-
> meta/recipes-qt/qt4/qt4_arch.inc | 3 +-
> meta/recipes-support/boost/boost-36.inc | 4 ++-
> meta/recipes-support/gmp/gmp.inc | 3 +-
> meta/recipes-support/libgcrypt/libgcrypt.inc | 3 +-
> meta/recipes-support/liboil/liboil_0.3.17.bb | 3 +-
> 19 files changed, 39 insertions(+), 51 deletions(-)
> delete mode 100644 meta/conf/machine/include/tune-thumb.inc
this causes ie eglibc not only to disable thumb but also to pass
-march=armv4 and look in wrong directory for toolchain.. which because
it's not filtering thumb is in armv4t-oe-linux-gnueabi
export PATH="
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi:
/OE/shr-core/tmp/sysroots/om-gta02/usr/bin/crossscripts:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:
/OE/shr-core/tmp/sysroots/x86_64-linux/sbin:
/OE/shr-core/tmp/sysroots/x86_64-linux//bin:
/OE/shr-core/openembedded-core/scripts:
/OE/bin:
/usr/local/bin:
/usr/bin:
/bin:
/opt/bin:
/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.1:
/OE/shr-core/openembedded-core/scripts"
simple forward of oe.dev arm-thumb.inc logic to arm-feature-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -5,7 +5,8 @@
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
+ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
seems to work.. will send patch after more testing, but eglibc compiled fine now..
Regards,
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES
2011-07-29 16:39 ` Martin Jansa
@ 2011-07-29 16:46 ` Khem Raj
2011-07-29 17:04 ` [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET Martin Jansa
1 sibling, 0 replies; 9+ messages in thread
From: Khem Raj @ 2011-07-29 16:46 UTC (permalink / raw)
To: openembedded-core
On 07/29/2011 09:39 AM, Martin Jansa wrote:
> On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
>> Currently when using thumb feature all recipes can not be compiled in
>> thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
>> set even when thumb was global choice. With this patch we remove thumb
>> from tune features for these recipes. This will make sure that compiler
>> is not using thumb options to compile these recipes at all.
>>
>> Signed-off-by: Khem Raj<raj.khem@gmail.com>
>> ---
>> meta/classes/qt4e.bbclass | 2 +-
>> meta/classes/qt4x11.bbclass | 2 +-
>> meta/conf/machine/include/tune-thumb.inc | 32 --------------------
>> meta/recipes-core/eglibc/eglibc.inc | 4 +-
>> meta/recipes-core/glib-2.0/glib.inc | 4 ++-
>> meta/recipes-core/glibc/glibc.inc | 4 ++-
>> meta/recipes-core/glibc/glibc_2.10.1.bb | 3 +-
>> meta/recipes-core/uclibc/uclibc.inc | 2 +-
>> meta/recipes-devtools/gcc/gcc-csl-arm-2008q1.inc | 3 +-
>> .../xorg-xserver/xserver-kdrive.inc | 4 ++-
>> meta/recipes-multimedia/alsa/alsa-lib_1.0.24.1.bb | 3 +-
>> .../gstreamer/gst-plugins-bad_0.10.21.bb | 3 +-
>> meta/recipes-multimedia/libmad/libmad_0.15.1b.bb | 4 ++-
>> meta/recipes-multimedia/tremor/tremor_20101121.bb | 4 ++-
>> meta/recipes-qt/qt4/qt4_arch.inc | 3 +-
>> meta/recipes-support/boost/boost-36.inc | 4 ++-
>> meta/recipes-support/gmp/gmp.inc | 3 +-
>> meta/recipes-support/libgcrypt/libgcrypt.inc | 3 +-
>> meta/recipes-support/liboil/liboil_0.3.17.bb | 3 +-
>> 19 files changed, 39 insertions(+), 51 deletions(-)
>> delete mode 100644 meta/conf/machine/include/tune-thumb.inc
>
> this causes ie eglibc not only to disable thumb but also to pass
> -march=armv4 and look in wrong directory for toolchain.. which because
> it's not filtering thumb is in armv4t-oe-linux-gnueabi
>
> export PATH="
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi.gcc-cross-initial:
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin/armv4-oe-linux-gnueabi:
> /OE/shr-core/tmp/sysroots/om-gta02/usr/bin/crossscripts:
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/sbin:
> /OE/shr-core/tmp/sysroots/x86_64-linux/usr/bin:
> /OE/shr-core/tmp/sysroots/x86_64-linux/sbin:
> /OE/shr-core/tmp/sysroots/x86_64-linux//bin:
> /OE/shr-core/openembedded-core/scripts:
> /OE/bin:
> /usr/local/bin:
> /usr/bin:
> /bin:
> /opt/bin:
> /usr/x86_64-pc-linux-gnu/gcc-bin/4.6.1:
> /OE/shr-core/openembedded-core/scripts"
>
> simple forward of oe.dev arm-thumb.inc logic to arm-feature-thumb.inc
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -5,7 +5,8 @@
> # but requires more instructions (140% for 70% smaller code) so may be
> # slower.
> TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
> +ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
>
> seems to work.. will send patch after more testing, but eglibc compiled fine now..
decoupling the -mthumb/-mno-thumb from thumb tune feature is right think
to do.
yes this would be something on the lines I was thinking can work with
minimal changes.
>
>
> Regards,
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 16:39 ` Martin Jansa
2011-07-29 16:46 ` Khem Raj
@ 2011-07-29 17:04 ` Martin Jansa
2011-07-29 17:10 ` Martin Jansa
1 sibling, 1 reply; 9+ messages in thread
From: Martin Jansa @ 2011-07-29 17:04 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
---
.../conf/machine/include/arm/feature-arm-thumb.inc | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index b580168..e7d392e 100644
--- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
+++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
@@ -5,7 +5,8 @@
# but requires more instructions (140% for 70% smaller code) so may be
# slower.
TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
+ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
# Note armv7 will hit on armv7a as well
--
1.7.6
^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 17:04 ` [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET Martin Jansa
@ 2011-07-29 17:10 ` Martin Jansa
2011-07-29 18:08 ` Mark Hatle
0 siblings, 1 reply; 9+ messages in thread
From: Martin Jansa @ 2011-07-29 17:10 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]
On Fri, Jul 29, 2011 at 07:04:33PM +0200, Martin Jansa wrote:
> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
> ---
> .../conf/machine/include/arm/feature-arm-thumb.inc | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> index b580168..e7d392e 100644
> --- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
> @@ -5,7 +5,8 @@
> # but requires more instructions (140% for 70% smaller code) so may be
> # slower.
> TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
> +ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
> OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
>
> # Note armv7 will hit on armv7a as well
> --
> 1.7.6
>
This seems to work, but be aware that _armv4t override is not respected
anymore :/.
I was using something like this to set default ARM_INSTRUCTION_SET from
distro config:
PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb"
PREFERRED_ARM_INSTRUCTION_SET_armv5te = "thumb"
PREFERRED_ARM_INSTRUCTION_SET_armv5teb = "thumb"
PREFERRED_ARM_INSTRUCTION_SET ?= "arm"
ARM_INSTRUCTION_SET = "${PREFERRED_ARM_INSTRUCTION_SET}"
but from -e output it's clear that it's ignored
# PREFERRED_ARM_INSTRUCTION_SET_armv4t=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv4t="thumb"
# PREFERRED_ARM_INSTRUCTION_SET=arm
PREFERRED_ARM_INSTRUCTION_SET="arm"
# PREFERRED_ARM_INSTRUCTION_SET_armv5te=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv5te="thumb"
# PREFERRED_ARM_INSTRUCTION_SET_armv5teb=thumb
PREFERRED_ARM_INSTRUCTION_SET_armv5teb="thumb"
# ARM_INSTRUCTION_SET=${PREFERRED_ARM_INSTRUCTION_SET}
ARM_INSTRUCTION_SET="arm"
Regards,
--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 17:10 ` Martin Jansa
@ 2011-07-29 18:08 ` Mark Hatle
2011-07-29 20:23 ` Phil Blundell
0 siblings, 1 reply; 9+ messages in thread
From: Mark Hatle @ 2011-07-29 18:08 UTC (permalink / raw)
To: openembedded-core
Sorry I was gone much of yesterday and not able to comment. I'm going to break
this down into the two problems that I see people having.
1) "interworking". I was recently told EABI requires interworking to be
enabled, and in OE-core we only support EABI. So we should always have the
interworking enabled for the tunes that we support.
Is this correct, any objections? If so, assume from this point forward
interworking is always enabled and we only support (in oe-core) interworking
capable ARM chips.
2) The tune naming is confusing people.
Initial design was (tune name):
armv5 = armv5 class CPU, with ARM instructions, w/ interworking enabled
armv5t = armv5 class CPU, with thumb instructions, w/ interworking enabled
The output of "armv5" was a package with the arch of "armv5", output of "armv5t"
was similarly "armv5t". Note, the package arch produced though is NOT the same
as the tune name, it just happens to be the same in these cases. (We could
easily call the tune names "armv5t_nothumb" and "armv5t_thumb" and still have
package arch of "armv5" and "armv5t".)
The confusion continues that people are expecting a package arch of "armv5t" to
be arbitrarily thumb or not thumb.. since the arch (to them) indicates that the
CPU is compatible with both thumb and ARM code. That was not the intent of this
change. Instead the _package architecture_ is designed to convey the ABI and
instruction set used when building the software in the package.
This not only helps with debugging what someone is using, but also helps with
designing filesystems that may contain both arm and thumb code. For example a
developer is building a device.. they have the requirements of "higher"
performance in there specific application, but maximum space savings everywhere
else. They want to start with a binary package feed, NOT the build system. So
they will mix and match the armv5 and armv5t packages by choosing the smaller
packages for most things (usually thumb), and using the ARM instruction set
where they need performance (usually armv5 packages).
---
So having a single value that simply switches the instruction set, without
changing the package arch violates the intent of the change. An alternative
would be something like:
feature-arm-thumb.inc:>
TUNEVALID[thumb] = "Support using thumb instructions"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb",
"${ARM_THUMB_M_OPT}", "", d)}"
ARM_THUMB_M_OPT = "${@['-mno-thumb',
'-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
OVERRIDES .= "${['', ':thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) ==
'thumb']}"
ARMPKGSFX_THUMB .= ${['', '_thumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1)
== 'thumb']}"
TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -mno-thumb"
tune-armv5.inc:
DEFAULTTUNE ?= "armv5t"
ARMPKGARCH ?= "armv5t"
TUNEVALID[armv5t] = "Enable instructions for ARMv5"
TUNE_CONFLICTS[armv5t] = "armv4"
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5t",
"-march=armv5t${ARMPKGSFX_DSP}", "", d)}"
ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5t", "dsp" ], "e",
"", d)}"
require conf/machine/include/arm/arch-armv4.inc
require conf/machine/include/arm/feature-arm-vfp.inc
require conf/machine/include/arm/feature-arm-thumb.inc
AVAILTUNES += "armv5t armv5te"
TUNE_FEATURES_tune-armv5t = "armv5 thumb"
TUNE_FEATURES_tune-armv5te = "armv5 dsp thumb"
(and some more lines for compatibility)
arch-arm.inc:
...
TUNE_PKGARCH = "${@d.getVar('ARMPKGARCH',
True)}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}${ARMPKGSFX_THUMB}"
----
When you select the tune of "armv5t" you will get classic ARM instructions with
the ability to enable thumb via ARM_INSTRUCTION_SET = thumb.
When you switch into building thumb (or out of it) the two produced package arch
will be:
armv5t
armv5t_thumb
This allows per packages switching using the ARM_INSTRUCTION_SET instead of
specific tune features, and still preserves the design of capturing the ABI &
instruction set in the package arch.
If this is reasonable, I'll work on a more complete patch set for this.
--Mark
On 7/29/11 12:10 PM, Martin Jansa wrote:
> On Fri, Jul 29, 2011 at 07:04:33PM +0200, Martin Jansa wrote:
>> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
>> ---
>> .../conf/machine/include/arm/feature-arm-thumb.inc | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc b/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> index b580168..e7d392e 100644
>> --- a/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> +++ b/meta/conf/machine/include/arm/feature-arm-thumb.inc
>> @@ -5,7 +5,8 @@
>> # but requires more instructions (140% for 70% smaller code) so may be
>> # slower.
>> TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
>> -TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "-mthumb", "-mno-thumb", d)}"
>> +ARM_THUMB_M_OPT = "${@['-mno-thumb', '-mthumb'][bb.data.getVar('ARM_INSTRUCTION_SET', d, 1) == 'thumb']}"
>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "${ARM_THUMB_M_OPT}", d)}"
>> OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
>>
>> # Note armv7 will hit on armv7a as well
>> --
>> 1.7.6
>>
>
> This seems to work, but be aware that _armv4t override is not respected
> anymore :/.
>
> I was using something like this to set default ARM_INSTRUCTION_SET from
> distro config:
>
> PREFERRED_ARM_INSTRUCTION_SET_armv4t = "thumb"
> PREFERRED_ARM_INSTRUCTION_SET_armv5te = "thumb"
> PREFERRED_ARM_INSTRUCTION_SET_armv5teb = "thumb"
> PREFERRED_ARM_INSTRUCTION_SET ?= "arm"
> ARM_INSTRUCTION_SET = "${PREFERRED_ARM_INSTRUCTION_SET}"
>
> but from -e output it's clear that it's ignored
> # PREFERRED_ARM_INSTRUCTION_SET_armv4t=thumb
> PREFERRED_ARM_INSTRUCTION_SET_armv4t="thumb"
> # PREFERRED_ARM_INSTRUCTION_SET=arm
> PREFERRED_ARM_INSTRUCTION_SET="arm"
> # PREFERRED_ARM_INSTRUCTION_SET_armv5te=thumb
> PREFERRED_ARM_INSTRUCTION_SET_armv5te="thumb"
> # PREFERRED_ARM_INSTRUCTION_SET_armv5teb=thumb
> PREFERRED_ARM_INSTRUCTION_SET_armv5teb="thumb"
> # ARM_INSTRUCTION_SET=${PREFERRED_ARM_INSTRUCTION_SET}
> ARM_INSTRUCTION_SET="arm"
>
> Regards,
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 18:08 ` Mark Hatle
@ 2011-07-29 20:23 ` Phil Blundell
2011-07-29 20:51 ` Mark Hatle
0 siblings, 1 reply; 9+ messages in thread
From: Phil Blundell @ 2011-07-29 20:23 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote:
> Sorry I was gone much of yesterday and not able to comment. I'm going to break
> this down into the two problems that I see people having.
>
> 1) "interworking". I was recently told EABI requires interworking to be
> enabled, and in OE-core we only support EABI. So we should always have the
> interworking enabled for the tunes that we support.
>
> Is this correct, any objections? If so, assume from this point forward
> interworking is always enabled and we only support (in oe-core) interworking
> capable ARM chips.
That's pretty much right though not 100% correct. Although it is true
that the AAPCS (and by extension the EABI) effectively requires all
relocatable objects to be built with interworking on, there are special
provisions for translating BX to MOV during link edit and hence allowing
v4 CPUs to run executables which are non-interworking but otherwise
conformant with the EABI. The effect of this is that, although v4 isn't
naturally an interworking-capable architecture, it is nonetheless
grandfathered into the EABI universe. See the remarks in section 5.6 of
ARM IHI 0042D.
And, pragmatically, there is a small but significant base of OE users on
v4 (not v4t) platforms and I don't think we want to do anything that
would disenfranchise them in OE-core.
Neither the AAPCS nor the wider EABI makes any attempt to cater for
architectures earlier than v4 and I don't think OE-core needs to do so
either. It's not totally unimaginable that someone might wish to target
OE-core at a v3 system but, if that ever happens, they can fill in the
missing bits in an overlay.
> The confusion continues that people are expecting a package arch of "armv5t" to
> be arbitrarily thumb or not thumb.. since the arch (to them) indicates that the
> CPU is compatible with both thumb and ARM code. That was not the intent of this
> change. Instead the _package architecture_ is designed to convey the ABI and
> instruction set used when building the software in the package.
It's worth pointing out, just in case it isn't already obvious, that an
individual package might contain a mixture of ARM and Thumb binaries,
and an individual binary might contain a mixture of ARM-state and
Thumb-state functions. This is doubly true when static libraries are
involved, of course. Some compilers may (although GCC doesn't, today)
even switch automatically between ARM-state and Thumb-state depending on
their view of which is going to give the best results.
So, the distinction between "arm" and "thumb" binaries is always going
to be a slightly blurry one and, although I can see the attraction of
being able to label a particular package as "arm" or "thumb", it's more
a question of picking points on a continuum than a binary switch.
> This not only helps with debugging what someone is using, but also helps with
> designing filesystems that may contain both arm and thumb code. For example a
> developer is building a device.. they have the requirements of "higher"
> performance in there specific application, but maximum space savings everywhere
> else. They want to start with a binary package feed, NOT the build system. So
> they will mix and match the armv5 and armv5t packages by choosing the smaller
> packages for most things (usually thumb), and using the ARM instruction set
> where they need performance (usually armv5 packages).
>
> ---
>
> So having a single value that simply switches the instruction set, without
> changing the package arch violates the intent of the change. An alternative
> would be something like:
It's not entirely obvious to me that Thumb-ness is, in this sense,
sufficiently special to deserve a distinct package architecture. After
all, one can already switch between -Os and -O99, or different -mtune
levels or no doubt many other things which influence code size and
performance without the package architecture changing. I guess some
DISTROs might want to offer a smorgasbord kind of approach where every
binary is compiled in N different ways and packaged separately, but I
get the general sense that most distros will probably not want to do
that and perhaps it oughtn't to be the default behaviour.
(And of course, on another pragmatic point, it isn't by any means
universally true that ARM-state has better performance than Thumb-state
on real world systems. There are a significant number of cases where
you get higher performance in Thumb-state than ARM-state.)
p.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 20:23 ` Phil Blundell
@ 2011-07-29 20:51 ` Mark Hatle
2011-07-30 9:41 ` Phil Blundell
0 siblings, 1 reply; 9+ messages in thread
From: Mark Hatle @ 2011-07-29 20:51 UTC (permalink / raw)
To: openembedded-core
On 7/29/11 3:23 PM, Phil Blundell wrote:
> On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote:
>> Sorry I was gone much of yesterday and not able to comment. I'm going to break
>> this down into the two problems that I see people having.
>>
>> 1) "interworking". I was recently told EABI requires interworking to be
>> enabled, and in OE-core we only support EABI. So we should always have the
>> interworking enabled for the tunes that we support.
>>
>> Is this correct, any objections? If so, assume from this point forward
>> interworking is always enabled and we only support (in oe-core) interworking
>> capable ARM chips.
>
> That's pretty much right though not 100% correct. Although it is true
> that the AAPCS (and by extension the EABI) effectively requires all
> relocatable objects to be built with interworking on, there are special
> provisions for translating BX to MOV during link edit and hence allowing
> v4 CPUs to run executables which are non-interworking but otherwise
> conformant with the EABI. The effect of this is that, although v4 isn't
> naturally an interworking-capable architecture, it is nonetheless
> grandfathered into the EABI universe. See the remarks in section 5.6 of
> ARM IHI 0042D.
>
> And, pragmatically, there is a small but significant base of OE users on
> v4 (not v4t) platforms and I don't think we want to do anything that
> would disenfranchise them in OE-core.
Which set of users is still v4 (not interworking compatible)? Are new
processors being made that still require that capability? or (in oe-core) is it
time to drop support?
Just because it's not in oe-core, doesn't mean it can't be in angstrom, or even
meta-oe as unique tunings for those architectures..
> Neither the AAPCS nor the wider EABI makes any attempt to cater for
> architectures earlier than v4 and I don't think OE-core needs to do so
> either. It's not totally unimaginable that someone might wish to target
> OE-core at a v3 system but, if that ever happens, they can fill in the
> missing bits in an overlay.
Ya, I never expected we'd support anything older the v4... but there is more
variation in v4 then I had realized.
>> The confusion continues that people are expecting a package arch of "armv5t" to
>> be arbitrarily thumb or not thumb.. since the arch (to them) indicates that the
>> CPU is compatible with both thumb and ARM code. That was not the intent of this
>> change. Instead the _package architecture_ is designed to convey the ABI and
>> instruction set used when building the software in the package.
>
> It's worth pointing out, just in case it isn't already obvious, that an
> individual package might contain a mixture of ARM and Thumb binaries,
> and an individual binary might contain a mixture of ARM-state and
> Thumb-state functions. This is doubly true when static libraries are
> involved, of course. Some compilers may (although GCC doesn't, today)
> even switch automatically between ARM-state and Thumb-state depending on
> their view of which is going to give the best results.
I didn't realize there were compilers that would switch states.. the others I
knew, but for the most part things are built on a package-level basis with a
single set of options for the whole package. (There will always be exceptions
of course.)
> So, the distinction between "arm" and "thumb" binaries is always going
> to be a slightly blurry one and, although I can see the attraction of
> being able to label a particular package as "arm" or "thumb", it's more
> a question of picking points on a continuum than a binary switch.
Currently the switching point is on a recipe basis. I'm sure we could make a
recipe that does both thumb and arm and do dynamic switching on a binary by
binary basis inside of a recipe.. but nothing that I am aware of does that
today. I've also not seen any real-world use cases that point to this --
outside of custom application code that is being specifically tuned for a device.
>> This not only helps with debugging what someone is using, but also helps with
>> designing filesystems that may contain both arm and thumb code. For example a
>> developer is building a device.. they have the requirements of "higher"
>> performance in there specific application, but maximum space savings everywhere
>> else. They want to start with a binary package feed, NOT the build system. So
>> they will mix and match the armv5 and armv5t packages by choosing the smaller
>> packages for most things (usually thumb), and using the ARM instruction set
>> where they need performance (usually armv5 packages).
>>
>> ---
>>
>> So having a single value that simply switches the instruction set, without
>> changing the package arch violates the intent of the change. An alternative
>> would be something like:
>
> It's not entirely obvious to me that Thumb-ness is, in this sense,
> sufficiently special to deserve a distinct package architecture. After
> all, one can already switch between -Os and -O99, or different -mtune
> levels or no doubt many other things which influence code size and
I've always seen -O levels set at the distribution or recipe level, not
dynamically changes as a user creates a system. Yes it can be done, but
practically speaking I don't see that.. (other then building say one recipe with
-O0 to facilitate in additional debugging, but that's not usually distributed
beyond the developer doing the individual work.)
> performance without the package architecture changing. I guess some
> DISTROs might want to offer a smorgasbord kind of approach where every
> binary is compiled in N different ways and packaged separately, but I
> get the general sense that most distros will probably not want to do
> that and perhaps it oughtn't to be the default behaviour.
again, if a distribution doesn't want to distinguish between thumb and not,
that's fine.. oe-core doesn't set distribution policy. But for oe-core it is a
use-case that I had in mind while doing much of the development. It's also a
use-case that I have active customers requesting from me...
> (And of course, on another pragmatic point, it isn't by any means
> universally true that ARM-state has better performance than Thumb-state
> on real world systems. There are a significant number of cases where
> you get higher performance in Thumb-state than ARM-state.)
Yup I'm aware of that as well.. which is why many customers want both ARM and
thumb versions of the software so they can compare the disk size vs performance
to meet whatever their targets are.. (most of the time for the OS it's purely
disk size.. their application is where they tune the performance characteristics.)
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET
2011-07-29 20:51 ` Mark Hatle
@ 2011-07-30 9:41 ` Phil Blundell
0 siblings, 0 replies; 9+ messages in thread
From: Phil Blundell @ 2011-07-30 9:41 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Fri, 2011-07-29 at 15:51 -0500, Mark Hatle wrote:
> Which set of users is still v4 (not interworking compatible)? Are new
> processors being made that still require that capability? or (in oe-core) is it
> time to drop support?
>
> Just because it's not in oe-core, doesn't mean it can't be in angstrom, or even
> meta-oe as unique tunings for those architectures..
FA5xx and FA6xx are both still current products and are v4 architecture.
The bulk of the users in OE today are StrongARM devices of one form or
another: those have obviously been discontinued for some time but there
still seem to be quite a lot of them around. So, I think it would make
sense to retain v4 support in oe-core.
> > It's not entirely obvious to me that Thumb-ness is, in this sense,
> > sufficiently special to deserve a distinct package architecture. After
> > all, one can already switch between -Os and -O99, or different -mtune
> > levels or no doubt many other things which influence code size and
>
> I've always seen -O levels set at the distribution or recipe level, not
> dynamically changes as a user creates a system. Yes it can be done, but
> practically speaking I don't see that.. (other then building say one recipe with
> -O0 to facilitate in additional debugging, but that's not usually distributed
> beyond the developer doing the individual work.)
Well, if your interest is in trading off size for speed, that's
precisely the distinction between -Os and -On. Indeed it isn't all that
hard to imagine that -mthumb might become the default for gcc at -Os,
and -mno-thumb might be the default at -O3. So, if you want a set of
"small" packages and a set of "fast" packages, it seems to me that the
most logical (and portable) way to do that is via -O level, rather than
tying it to ISA specifically.
p.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-07-30 9:45 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-29 14:59 [PATCH] classes, recipes: Replace use of ARM_INSTRUCTION_SET with contruct using TUNE_FEATURES Khem Raj
2011-07-29 16:39 ` Martin Jansa
2011-07-29 16:46 ` Khem Raj
2011-07-29 17:04 ` [PATCH] feature-arm-thumb: respect ARM_INSTRUCTION_SET Martin Jansa
2011-07-29 17:10 ` Martin Jansa
2011-07-29 18:08 ` Mark Hatle
2011-07-29 20:23 ` Phil Blundell
2011-07-29 20:51 ` Mark Hatle
2011-07-30 9:41 ` Phil Blundell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox