Hi folks,
We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is
/lib/arm-linux-gnueabihf/ld-linux.so.3
but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.
This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.
I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04 || 2012-02-01 ||
== other ==
* cleaned up and refactored QEMU GIC/NVIC code enough to provide
a solid foundation for the in-kernel irqchip support. Posted
the refactoring bits to qemu-devel. This should be enough to
unblock Marc Z.
* qemu-linaro: LP:978694: added patch from Peter Chubb fixing
beagle bootrom FAT12/FAT16 handling
* finished a trivial bit of cleanup of an omap3 ID register patch
I'd had lying around half-done for a while
* investigating a bug reported by Alex Graf where we get a segfault
gtk-query-immodules-2.0 but only if qemu's 'reserve memory space'
feature is being used: this appears to be an interestingly nasty
case where if the guest does mmap(dll); execute code in dll;
munmap(); mmap(dll 2); execute code in dll 2; and the two mmap()s
happened to pick the same address then we will end up using a
stale cached translation from dll 1 when executing dll 2...
-- PMM
== GCC ==
* Completed testing and benchmarking of patch to use vld1/vstd1
instead of vldm/vstdm for vector moves. Saw no regressions but
only minor benefits.
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to FSF mainline and 4.7 branch; backports to Linaro GCC 4.7 and 4.6
pending.
* Checked in mainline patch to enable -fsched-pressure by default
on s390.
* Ongoing work on improving end-of-loop value computation.
* Started investigation of TSVC vectorizer test kernels.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi Uli,
While looking into something else I ran into these - I wonder how many
of these GCC manages to vectorize ...
http://www.netlib.org/benchmark/livermorec . These look interesting
from a vectorizer kernels point of view.
The other interesting paper of note was this PACT paper on
vectorization benchmarks comparing icc , xlc and GCC which might
provide some interesting hints / reading.
http://polaris.cs.uiuc.edu/~garzaran/doc/pact11.pdf . The appropriate
benchmarks kernels are linked to below.
http://polaris.cs.uiuc.edu/ ̃maleki1/TSVC.tar.gz.
regards,
Ramana
I've put the agenda for Monday's call at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-05-07
which is:
* Review action items from last meeting
* Connect sessions:
* GDB for Android
* GCC performance call - Live!
* KVM performance
* Renderscript
* Android benchmarking
* Dalvik improvements
* Hard float switchover status
* multiarch upstreaming
* Next week is release week
* vld1, EEMBC results, and noise
* twolf result variance
* KVM minimum features
* UP/UP, Ubuntu
* [[MichaelHope/Sandbox/KVMUseCase]]
Feel free to edit,
-- Michael
I've done some minor updates to the instructions for working with
gcc-linaro, bzr, and merge requests at:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
The interesting changes are using:
* bzr commit --fixes=lp:nnnn to link a branch to a bug number
* bzr branch --hardlink to cut down on branch time and disk usage
* bzr-merge-changelog to automatically merge ChangeLog.linaro
-- Michael
Greetings,
I successfully built BusyBox using the 4.5.2 toolchain. When I try to build BusyBox using the same config with the 4.6.3 toolchain I get the following error:
The Linaro 4.5.2 toolchain was installed in my Ubuntu 11.04 distro using aptitude.
The Linaro 4.6.3 toolchain binaries, downloaded via Launchpad, were installed into my own tools directory.
busybox # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
scripts/kconfig/conf -s Config.in
can't find file Config.in
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [include/autoconf.h] Error 2
I get the same error if I try 'make oldconfig' or 'make menuconfig'.
Is there a PATH I need to set? Am I missing a package?
Right now my PATH has following 4.6.3 directories set:
linaro-4.6.3/bin
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
linaro-4.6.3/arm-linux-gnueabi/libc/lib/arm-linux-gnueabi
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
Thanks,
Dan
I thought I'd send an update on the SPEC 2000 twolf variance. We're
seeing a high amount of variance in the results for the SPEC 2000
twolf, vpr, and galgel benchmarks. I've run tests on a PandaBoard,
Origen, and IGEPv2 and gotten a coefficent of variance of 0.014,
0.017, and 0.003 which suggests that the problem is Cortex-A9
specific. twolf is hard on the cache so my theory is that it's
something to do with the memory subsystem. I currently have a
PandaBoard running with SMP, heap randomisation, virtual address
randomisation, and the branch predictor off and the CPU down clocked
to the non-overdrive 600 MHz. I'll let this run overnight and see if
the results are tighter.
To solve Andrew's immediate problem, I'm running SPEC on the 64 bit
core register shifts on the OMAP3. The results are tight enough that
we should be able to show any regressions.
-- Michael
