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
I added Ubuntu 12.04 'precise' based sysroots to Jenkins yesterday. They
are built using 'armhf' architecture and available in three flavours:
- alip
- nano
- ubuntu-desktop
So far only -dev ones are present, will work on -dbg ones soon.
We have 'nano' one built and available to fetch at
http://snapshots.linaro.org/precise/images/nano-dev/ - rest will be
built when there will be machine free to do that.
They will also be moved to http://snapshots.linaro.org/precise/sysroots/
to not make people try to boot them ;)
Please take a look do they work as you want and tell me what kind of
changes you would like to have, which images are not needed, which
should be added. Are there any users for -dbg style sysroots?
I did see gcc-4.7 fail to build for an sf/hf multilib configuration. The reason
was that gcc -print-multi-directory didn't print anything for the non-default,
and gcc -print-multi-lib only prints `.'. The reason is that set_multilib_dir
in gcc.c only consults MULTILIB_DEFAULTS (only defined in linux-elf.h), but not
the default configure options in configargs.h. This proposed patch updates
MULTILIB_DEFAULTS depending on the configure options. An alternative approach
would be to update set_multilib_dir and print_multilib_info to lookup the
configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what change
did cause the build failure.
Matthias
* Linaro
Continued looking at the lower-subreg problem (that the lowering is only
really intended for 32-bit targets that don't have 64-bit operation).
Without NEON this is only really a problem for "ldrd/strd" 64-bit loads
and stores: the patterns are all (or should be all) written such that
they only access DImode regs via SUBREG, so it all works well. When
adding NEON 64-bit this becomes less clear: many operations must remain
in DImode without SUBREG until after register allocation. The
lower-subreg passes mostly cope with this well enough, but it has some
features that attempt to lower zero_extends, certain shifts, and
pseudo-reg copies, unconditionally. I've been investigating what happens
if I disable the pseudo-reg copy "optimization" in the first
lower-subreg pass. As I expected, in many cases it actually leads to
smaller code (more use of LDRD/STRD) without NEON, and even better
results with NEON. Unfortunately I have found so counter-examples, so
I'm trying to figure out what's going on there: for some reason reload
goes crazy and starts spilling things to the stack, even though I can't
see that more registers are required. More investigation required.
Richard E approved my NEON-immediates patch for upstream. I don't have
time to commit it with proper care this week, so that's delayed to next
week.
* Other
Vacation Monday and Tuesday. Had a fun long weekend in Cornwall with my
family.
Progress
Away last week - nothing to report. Will be in BST + 4:30 timezone
this week.
Plans
* Finish off the VFP addressing modes patch.
* Follow up on iterations idiom patch upstream
* Pursue backporting gnu_unique_object upstream.
* Look at some of the existing blueprints and start discussions around
prioritizing this.
* Investigate some of the SEGVs with h-c partitioning in the future.
Hi Zhenqiang. Ubuntu Precise is now out and has switched to hard
float by default. I want to do the same for the next binaries
release. Here's the work that needs to be done:
* Bring in the new sysroot
* Change the triplet to arm-linux-gnueabihf
* Change GCC's configure so it recognises the new triplet
* Change the default float ABI to hard
We should include a soft float (not softfp) multlib libgcc for those
who use the binary toolchain to build bare metal programs like u-boot
or the kernel. They don't use floating point, but the linker will
complain about mixed calling conventions.
I've updated make-sysroot.sh and spun an experimental sysroot at
http://people.linaro.org/~michaelh/incoming/precise-sysroot-armhf-r0.tar.bz2.
Hopefully we'll use Marcin's ones instead.
Matthias has patches for many of these changes. Let's talk about it
at tonight's meeting.
Could you start on these? I'd like the changes done within two weeks
so we have plenty of time to test.
-- Michael
Summary:
* Linaro binary toolchain 2012.04 release.
* Code size benchmark analysis.
Details:
1. Validate and bug fix for linaro binary toolchain 2012.04 release.
2. Investigate code size regressions in 4.7
Find more regression cases due to loop invariant hoisting, and tests
should we can reduce some codesize with option
-fno-move-loop-invariants. Some regressions are due to
pass_reorder_blocks, which is disabled for -Os in 4.7. For some cases,
ivopt will introduce to more codes and function inline might lead to
more spilling. We also try linaro 2012.04 baremetal build. But there
is a few bytes regression compared with 4.7 trunk.
3. Setup the qemu env following Michael’s instructions
(https://wiki.linaro.org/MichaelHope/Sandbox/QEMUCrossTest) and tests
show it work.
4. Try to build gcc-linaro-2012.04 configured with "--with-fpu=neon
--with-float=hard" based on a precise sysroot
(precise-sysroot-armhf-r0.tar.bz2) from
http://people.linaro.org/~michaelh/incoming
* Linux build is OK without any change.
* Mingw32 build reports error. After removing the code, the build PASS.
[ERROR] .../libc/usr/include/arm-linux-gnueabihf/sys/types.h:117:19:
error: two or more data types in declaration specifiers
Plans:
* Investigate other code size regressions in 4.7.
Planed leaves:
* Labor Day holiday: April 30 and May 1.
Best regards!
-Zhenqiang
Hi,
OpenEmbedded-Core/meta-linaro:
* pushed support for Linaro GCC 4.6.4 2012.04 and for the
2012.03-20120326 binary toolchain
* updated the wiki
* created a branch to support GCC 4.7
* built several images using several GCC 4.7 based toolchains (OE,
linaro 4.7.1, binary toolchain 2012-04)
* minimal images are working
* sato image shows splash screen forever (won't bring up the
matchbox window manager)
* only when using the binary toolchain 2012-04 ? -> needs to be
analyzed
* Qt 4.8 requires small patches (posted and merged into
oe-core/master-next)
Libunwind:
* User reports issues when backtracing through signal frame
* reason: the lib falls back on APCS frame parsing which usually
segfaults on EABI systems
* provided debugging hints and insights on how libunwind handles
signal frames
* posted a reduced testcase
Regards,
Ken
