cross-distro

cross-distro@lists.linaro.org

1 participants
221 discussions

by Steve McIntyre

Hi folks, 1. eglibc patch for distinguishing ABI at runtime in ld.so I've submitted the patch I was working on, but it's not looking like the eglibc folks are very interested in its current form. There are suggestions on how to proceed with re-engineering it - see the short thread at http://www.eglibc.org/archives/patches/msg01017.html for more info. Being honest, I'm tempted to just leave this work as a proof of concept at this stage. It'll take quite a while to go down the ELF header route, and I fear that we'd have to wait for a lot of changes to flush through before we can get anywhere here. The change to the location of ld.so to move it to the triplet path /lib/arm-linux-gnueabihf/ should be good enough for our purposes anyway. 2. gcc patch to move ld.so to /lib/arm-linux-gnueabihf/ I've been testing and tweaking dannf's gcc patch as proposed at http://lists.linaro.org/pipermail/cross-distro/2011-October/000078.html to get to the attached patch. I've updated it to match the comments that were made here, and it seems to work fine for me: root@panda-smcintyre:/home/steve/src# strings /bin/ls | grep /ld /lib/ld-linux.so.3 root@panda-smcintyre:/home/steve/src# strings ./test | grep /ld /lib/arm-linux-gnueabihf/ld-linux.so.3 Can anyone think of any reasons to not submit it now? Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 9 months

Meetings at Linaro Connect next week

by Steve McIntyre

Hi folks, I've added blueprints for the LC/UDS conference in Orlando next week as placeholders for two meetings that I think should be useful: 1. linaro-octo-armhf-status Updates on where we are with the different ports for v7 using the hard-float ABI. There's still some work to do, but it seems that much of it is done at this point. Let's review where we've got to, and what work is left. 2. linaro-summits-cross-distro Continuing cross-distribution meeting series, aimed at sharing ideas and problems that people may have related to ARM porting. There was a good and useful session at Plumbers last month, and we agreed to keep going on these meetings. Let's see how people are getting on and what's new. Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 9 months

RE: Arm System Calls Numactl

by webwillow＠thewebwillow.com

14 years, 10 months

RE: Arm System Calls Numactl

by webwillow＠thewebwillow.com

14 years, 10 months

RE: Arm System Calls Numactl

by webwillow＠thewebwillow.com

14 years, 10 months

Arm System Calls Numactl

by webwillow＠thewebwillow.com

14 years, 10 months

ARM febootstrap-2.11 consult from teh experts?

by webwillow＠thewebwillow.com

14 years, 10 months

About arm choice of toolchain options

by Paulo César Pereira de Andrade

Hi, Sorry for the cross post and long email :-) Currently I am working on a very initial state build of Mandriva for arm. Thanks to Jeff Johnson for giving me ssh access to armv7 hosts, and Matthew Dawkins for building several Mandriva/Unity linux armv5 packages. What I am trying to understand now is about choice of float abi. I understand that the IHI0042D_aapcs.pdf file I donwload says to use vfp registers for float/double arguments, but softfp seems too good to miss, as armv5 should be around for some time yet. So, I have two chroots, running: softfp# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) thumb# gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/armv7l-mandriva-linux-gnueabi/4.6.1/lto-wrapper Target: armv7l-mandriva-linux-gnueabi Configured with: /home/pcpa/bootstrap/rpmbuild/BUILD/gcc-4.6-20110722/configure --prefix=/usr --build=i586-mandriva-linux-gnu --host=armv7l-mandriva-linux-gnueabi --target=armv7l-mandriva-linux-gnueabi --enable-werror=no --enable-cxx --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-arch=armv7-a --with-mode=thumb --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux --enable-languages=c,c++ --enable-threads=posix --disable-libssp --disable-libmudflap Thread model: posix gcc version 4.6.1 20110722 (Mandriva) (GCC) This is unmodified upstream gcc, and using a set of bootstrap scripts from a git branch I made on a checkout of git clone git://fedorapeople.org/~djdelorie/bootstrap.git Since I am still very "arm noob" :-) and just yesterday did the thumb build to learn about thumb, so far, my impression is that the best approach should be to use thumb+softfp. Just so you know I am running thumb and arm builds, with thumb using hard float and the softfp with arm instructions set: softfp# objdump -d /usr/lib/libm.so | less [...] 00008d30 <__ieee754_atan2>: 8d30: e3a0c000 mov ip, #0 8d34: e347cff0 movt ip, #32752 ; 0x7ff0 8d38: e92d4030 push {r4, r5, lr} 8d3c: ed2d8b10 vpush {d8-d15} 8d40: e3a05000 mov r5, #0 8d44: ec432b18 vmov d8, r2, r3 8d48: e3475ff0 movt r5, #32752 ; 0x7ff0 8d4c: e003c00c and ip, r3, ip 8d50: e15c0005 cmp ip, r5 8d54: e24dd02c sub sp, sp, #44 ; 0x2c 8d58: e1a04003 mov r4, r3 8d5c: ec410b19 vmov d9, r0, r1 8d60: e1a05002 mov r5, r2 8d64: 0a000022 beq 8df4 <__ieee754_atan2+0xc4> [...] thumb# objdump -d /usr/lib/libm.so | less [...] 00007884 <__ieee754_atan2>: 7884: 2100 movs r1, #0 7886: 2000 movs r0, #0 7888: f6c7 71f0 movt r1, #32752 ; 0x7ff0 788c: ec53 2b11 vmov r2, r3, d1 7890: f6c7 70f0 movt r0, #32752 ; 0x7ff0 7894: 4019 ands r1, r3 7896: 4281 cmp r1, r0 7898: e92d 03f0 stmdb sp!, {r4, r5, r6, r7, r8, r9} 789c: ed2d 8b10 vpush {d8-d15} 78a0: 461c mov r4, r3 78a2: b08a sub sp, #40 ; 0x28 78a4: eeb0 8b41 vmov.f64 d8, d1 78a8: 4616 mov r6, r2 78aa: eeb0 9b40 vmov.f64 d9, d0 78ae: d03c beq.n 792a <__ieee754_atan2+0xa6> [...] I am kind of trying to figure what "The Industry" says about it, and just checked the linaro gcc-4.6 relevant changes for me right now, that are... + --with-arch=armv7-a --with-tune=cortex-a8 \ + --with-float=$(float_abi) --with-fpu=neon \ +# check if we're building for armel or armhf +ifeq ($(DEB_TARGET_ARCH),armhf) + float_abi := hard +else ifneq (,$(filter $(DEB_TARGET_ARCH), arm armel)) + float_abi := softfp +endif If I understand correctly, neon will have better support for simd instructions right? Either way, I used two simple benchmarks to try to sell myself the idea of breaking compatibility with armv5 or older binaries, but still not convinced, but, as I said, we should use whatever "The Industry" chooses :-) I used for benchmark http://www.tux.org/~mayer/linux/bmark.html and http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Why-ARMs-EABI… and also compared with my home computer (quad)core i5 x86_64, and attached results... Thanks and again sorry for cross posting and long email, Paulo

14 years, 10 months

hard-float linker check benchmarks

by Steve McIntyre

Hey folks, My first prototype changes to ld.so (see the attached patch) seem to work ok, and my code will now complain (and fail) appropriately if you try to mix soft-float ABI and hard-float ABI binaries in the same process. I think the working code for the patch itself is clean enough, but at the moment it's hacked in and I'm looking for a cleaner way to integrate it. In the meantime, I've been benchmarking the cost of checking each of the binaries at startup. I've got a script that does: * flush caches * time ld.so $binary --version n times in a loop, and times each run so I can calculate the mean and standard deviation. I've tested four different programs (ls, emacs, iceweasel and kcalc) to give a spread of sizes. Full figures below. Quick summary: the extra work of checking does not seem to have any noticeable bad effect on program startup. In some cases it even seems to make things faster! But in all cases the differences between "check" and "nocheck" are well within the standard deviation from the testing, so I'm happy. I've measured the effects using Debian armel and armhf chroots on my Panda board, but the specific versions of software and the target CPU version vary armel/armhf so please don't compare the numbers in that direction! Debian armel (v4t, soft-float ABI), using --version: ==================================================== Test using /bin/ls --version, running 100 times Results from /tmp/time.2592, 100 runs of "ls" using "check": Total times real 35.20 user 0.00 sys 0.00 Mean times real 0.352 user 0.000 sys 0.000 stddev real 0.068 user 0.000 sys 0.000 Test using /bin/ls --version, running 100 times Results from /tmp/time.3305, 100 runs of "ls" using "nocheck": Total times real 35.27 user 0.00 sys 0.00 Mean times real 0.353 user 0.000 sys 0.000 stddev real 0.069 user 0.000 sys 0.000 Test using /usr/bin/emacs23-x --version, running 100 times Results from /tmp/time.5448, 100 runs of "emacs23-x" using "check": Total times real 519.23 user 1.32 sys 3.20 Mean times real 5.192 user 0.013 sys 0.032 stddev real 0.430 user 0.015 sys 0.012 Test using /usr/bin/emacs23-x --version, running 100 times Results from /tmp/time.6166, 100 runs of "emacs23-x" using "nocheck": Total times real 507.24 user 1.31 sys 3.17 Mean times real 5.072 user 0.013 sys 0.032 stddev real 0.302 user 0.012 sys 0.010 Test using /usr/lib/iceweasel/firefox-bin --version, running 100 times Results from /tmp/time.6880, 100 runs of "/usr/lib/iceweasel/firefox-bin" using "check": Total times real 668.45 user 1.69 sys 6.29 Mean times real 6.684 user 0.017 sys 0.063 stddev real 0.692 user 0.018 sys 0.019 Test using /usr/lib/iceweasel/firefox-bin --version, running 100 times Results from /tmp/time.7696, 100 runs of "/usr/lib/iceweasel/firefox-bin" using "nocheck": Total times real 651.27 user 1.73 sys 6.27 Mean times real 6.513 user 0.017 sys 0.063 stddev real 0.557 user 0.020 sys 0.019 Test using /usr/bin/kcalc --version, running 100 times Results from /tmp/time.4018, 100 runs of "kcalc" using "check": Total times real 1249.40 user 5.77 sys 7.41 Mean times real 12.494 user 0.058 sys 0.074 stddev real 0.887 user 0.022 sys 0.021 Test using /usr/bin/kcalc --version, running 100 times Results from /tmp/time.4733, 100 runs of "kcalc" using "nocheck": Total times real 1240.01 user 5.29 sys 7.89 Mean times real 12.400 user 0.053 sys 0.079 stddev real 0.786 user 0.020 sys 0.019 Debian armhf (v7, hard-float ABI), using --version: =================================================== Results from /tmp/time.7128, 100 runs of "ls" using "check": Total times real 26.52 user 0.00 sys 0.00 Mean times real 0.265 user 0.000 sys 0.000 stddev real 0.058 user 0.000 sys 0.000 Test using /bin/ls --version, running 100 times Results from /tmp/time.7843, 100 runs of "ls" using "nocheck": Total times real 24.74 user 0.00 sys 0.00 Mean times real 0.247 user 0.000 sys 0.000 stddev real 0.038 user 0.000 sys 0.000 Test using /usr/bin/emacs23-x --version, running 100 times Results from /tmp/time.9991, 100 runs of "emacs23-x" using "check": Total times real 548.08 user 2.26 sys 2.40 Mean times real 5.481 user 0.023 sys 0.024 stddev real 0.630 user 0.017 sys 0.015 Test using /usr/bin/emacs23-x --version, running 100 times Results from /tmp/time.10705, 100 runs of "emacs23-x" using "nocheck": Total times real 549.29 user 2.15 sys 2.43 Mean times real 5.493 user 0.022 sys 0.024 stddev real 0.600 user 0.019 sys 0.016 Test using /usr/lib/iceweasel/firefox-bin --version, running 100 times Results from /tmp/time.11423, 100 runs of "/usr/lib/iceweasel/firefox-bin" using "check": Total times real 620.18 user 1.75 sys 5.98 Mean times real 6.202 user 0.018 sys 0.060 stddev real 0.682 user 0.019 sys 0.019 Test using /usr/lib/iceweasel/firefox-bin --version, running 100 times Results from /tmp/time.12237, 100 runs of "/usr/lib/iceweasel/firefox-bin" using "nocheck": Total times real 636.31 user 1.77 sys 5.95 Mean times real 6.363 user 0.018 sys 0.060 stddev real 0.766 user 0.018 sys 0.020 Test using /usr/bin/kcalc --version, running 100 times Results from /tmp/time.8556, 100 runs of "kcalc" using "check": Total times real 1338.36 user 7.00 sys 5.41 Mean times real 13.384 user 0.070 sys 0.054 stddev real 1.223 user 0.031 sys 0.029 Test using /usr/bin/kcalc --version, running 100 times Results from /tmp/time.9275, 100 runs of "kcalc" using "nocheck": Total times real 1345.21 user 7.46 sys 5.02 Mean times real 13.452 user 0.075 sys 0.050 stddev real 1.197 user 0.031 sys 0.030 Cheers, -- Steve McIntyre steve.mcintyre(a)linaro.org <http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

14 years, 10 months

Bring Sheeva Plug Back on Centos

by webwillow＠thewebwillow.com

14 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

cross-distro