Hi Ken. I've checked in a rough script that builds OpenEmbedded
inside the cbuild Makefile-based auto builders.
To run it yourself:
* bzr branch lp:cbuild
* cd cbuild
* cp oecore.mk lib
* mkdir -p slaves/`hostname`
* cd slaves/`hostname`
* make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under
cbuild/lib. The steps are driven by steps.mk which use stamp files to
see what is finished and what needs running. The normal steps are
configure; build; install; testsuite; run. I've split the build and
similar steps into one per architecture and added a ping to the
scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each
one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level
build directory is $LBUILD (gcc-native/oecore). The variant build
directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant).
The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES
and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as
using the vexpress-a9 model. Use patch-% as the fallback and the
specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are
snapshotted on change:
* kwerner/meta-linaro
* openembedded-core/denzil
and end up at:
http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script
uses my normal tactics:
* Everything over HTTP
* Use a in-network proxy, set in ~/.wgetrc
* Pull from a mirror first or only
(http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/ > ~/.wgetrc.
I've seeded the mirror. We should keep track of any extras needed
such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk.
Might speed the build and not wear the build disk out.
-- Michael
Hi,
GDB for Android:
* Reviewed Carlos O'Donell response to my message in lsb-discuss to think
about the pros and cons of the approaches he mentioned, did some
investigation. Maybe the ABI-tag is not needed, at least for debugging
purposes (there may be other uses).
* Wrote patch which detects an Android app by looking at the ELF
interpreter field in the binary.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Struggled with creating and running a Linaro Android 2012.04 QEMU image.
* Failed to set up a network between the image and the host to run
gdbserver on it.
* Studied how GDB copes with uclibc and dietlibc regarding the jump buffer
format to compare it how Android GDB solves the problem. It turns out
that they both use the same format that glibc uses so nothing is needed
on GDB side.
* Researched Pandaboard and accessories to purchase.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
* Linaro
Continued trying to understand lower-subreg and its impact on ARM
optimization. After much staring at RTL dumps and trying to minimize
test cases from large code bases I've not found an example of code where
disabling the lowering of pseudo-to-pseudo copies made the code larger
for anything other than unfortunate random knock-on effects (such as no
longer being able to use 16-bit thumb1 opcodes). I posted a message to
this effect on the gcc list, and I'll try benchmarking a patch for this
next week.
In the process of looking at lower-subreg, discovered a silly
missed-optimization bug with many DImode operations, and reported it to
GCC Bugzilla as pr53189.
Hi,
OpenEmbedded-Core/meta-linaro:
* created meta-linaro denzil branch to be used in conjunction with the
oe release
* added a patch that prevents GCC from installing libssp and
libstdc++-v3 to lib64 on X86_64 Linux
* merged patches that use vexpress defconfig only for qemuarmv7a
* built and tested all supported QEMU tarted (ARM, MIPS, PPC, X86,
X86_64) using Linaro GCC 4.6 2012.04
* All images (minimal, sato and Qt) are booting!
* started to work on the automation
Regards,
Ken
Summary:
* arm-linux-gnueabihf and multilib support for linaro toolchain.
* Code size benchmark analysis.
Details:
1. arm-linux-gnueabihf support for linaro toolchain
* Update gcc, libgcc and libstdc++ config to support the triplet.
* Update build scripts to gnueabihf.
* Add sample config for gnueabihf.
2. Multilib support for linaro toolchain
* Merge Terry's multilib patches
(http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00975.htmlhttp://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083.html) and revise
them for linaro.
* Update gcc.c and incpath.c to make multiarch and multilib work together.
* libgcc for armv4t (-mfloat-abi=soft) build fail: ld: error:
armv4t/libgcc_s.so.1.tmp uses VFP register arguments, ... does not.
Root cause: crt*.o from precise sysroot use VFP_args, while other
objects are built with -mfloat-abi=soft. We need additional crt*.o to
build libgcc for armv4t.
3. Code size regression analysis
We find more regression cases introduced by ivopt and loop invariant.
Plans:
* Investigate other code size regressions in 4.7.
* Finalize the arm-linux-gnueabihf and multilib support for linaro toolchain.
Best regards!
-Zhenqiang
I've lost track of the benchmark builds so I've started a manual todo list at:
https://wiki.linaro.org/MichaelHope/Sandbox/Todo
It's been messy with the validation lab being down and some builds
being in my home office and some in Cambridge. Let me know if I'm
missing any.
-- Michael
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
