Hi,
GDB for Android:
* Wrote first draft of the GDB for Android card.
* Found out that there actually is a libthread_db.so in /system/lib
and was able to compile (after a small hack) an FSF gdbserver 7.3
which uses the libthread_db.so from Android and correctly shows
all threads in the process. So the libthread_db.so from Android
actually works, still have to learn why they don't use it.
* Tried to compile a native GDB which uses libthread_db.so but no
luck so far. There are many differences in bionic's header files
which upset libiberty and gnulib which are not easy to work around.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
We now do a SPEC ref run when benchmarking. I've updated the
linaro-toolchain-benchmarks scripts to handle the changes and spawned
some historical builds to do comparisons. All earlier builds have
been archived to prevent confusion.
The human readable summary is now also included in the results. See:
http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.6-2012.02/logs/armv7l-nat…
for an example.
Half an hour to build, 26 hours to run. Not too bad.
-- Michael
Here's brief notes on running different benchmark variants across the
auto builders. Asa, could you pull these plus your notes into a wiki
page?
Spawn a job:
http://ex.seabright.co.nz/helpers/scheduler/spawn
Merge requests are automatically built. Otherwise, drop arbitrary
tarballs into cbuild@orion:~/snapshots and spawn <tarball name minus
extension>. For example, scp gcc-4.6.3.tar.gz
cbuild@orion:~/snapshots; spawn gcc-4.6.3 into a9-builder.
Jobs:
* gcc-version - build and test GCC
* benchmarks-gcc-version - run coremark, denbench, eembc against the
already built version
* benchmarks-spec2000-gcc-version - run spec2000
Queues:
* a9-builders: anything that can naive build a A9 compiler
* a9-ref: reference A9 boards
* a8-ref: reference A8 boards
Variables:
* BENCHMARKS = list, such as coremark spec2000 pybench - run these
benchmarks instead of the defaults
Variants:
* By default we build o3-neon
* See http://bazaar.launchpad.net/~linaro-toolchain-dev/cbuild/trunk/view/head:/l…
for all names
* Spawn a job with VARIANT_SRC = all and VARIANT_LIST = glob-pattern
Examples:
* VARIANT_LIST = o3-neon o3-vfpv3 (compare NEON with VFPv3D32)
* VARIANT_LIST = o3-neon-cortexa8 o3-neon-cortexa9 (compare
-mtune=cortexa8 vs -mtune=cortexa9(
* VARIANT_LIST = o3-neon-novect o3-neon (compare with/without the vectoriser)
-- Michael
I'd like to announce a change in how the Linaro Toolchain group notify
about our monthly releases. In the past we've sent one email per
product to the linaro-announce list. From this week forward a summary
of all products will be included in the main, end of month
announcement instead.
We'll continue to send a per product emails to the linaro-toolchain
list when the mid-month release is available. If you'd like to get
things two weeks early, please subscribe[1]. You can filter on the
word '[ANNOUNCE]' to filter out the development chatter. A RSS feed
is also available[2].
-- Michael
[1] http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[2] http://feeds.launchpad.net/linaro-toolchain/announcements.atom
All,
I need to supply a Linaro toolchain "aligned" (same source code)
bare-metal compiler to a group doing benchmarking on A15.
First off my assumption is that we will write our own boot and semi
hosting code. (semi-hosting for TI emulators/simulators is different
than ARM RDI semi-hosting.)
I was planning on looking at the two toolchains here[1] and here [2]:
[1] https://launchpad.net/linaro-toolchain-binaries
[2] https://launchpad.net/gcc-arm-embedded
I was then going to build a hybrid that was newlib based but appropriate
for armv7-a (instead of cortext-m3) and maybe even -mtune'ed for A15.
However looking at the gcc-arm-embedded release more[3] I see that it
supports ARMv7-R. It supports both thumb and non-thumb modes, both
softfp and hardfp ABIs.
What would I really gain by building my own? For app code the user
should be able to add -mtune=cortex-a15 and still be compatible with the
pre-built R4/R5 libraries. The only performance difference should be in
the library code and that should be only pipeline tuning if I understand
the difference between armv7-a and armv7-r correctly.
Am I missing something? Should I build my hybrid anyway?
[1] https://launchpadlibrarian.net/88152755/readme.txt
[BTW: has the below project been obsoleted by the gcc-arm-embedded one?
Perhaps gcc-arm-embedded should be referenced in the description of
the page below.
https://launchpad.net/linaro-toolchain-unsupported ]
Thanks,
Bill
Committed the 4.6.3 merge to Linaro GCC 4.6.
Merged from FSF 4.5 to Linaro GCC 4.5.
Thought about how to do register-class allocation for NEON v. core
registers case. Discussed the problem at the GCC performance meeting.
Lots of interesting discussion was had. I have some interesting
experiments to do, but the first step needs to be to get my 64-bit
operator patch to work correctly.
Tried to track down the problems in my NEON-immediates patch. The
problem is that it's putting constants in different pools in stage 3 to
what it does in stage 2. Presumably this is something to do with the
pool-offset attributes in the instruction patterns? My patch has caused
it to switch from using 'fldd' to using 'vmov' in some cases (the
instructions are aliases, but it's indicative of a different machine
description pattern in the compiler), but I don't know why the change
would be different between the different bootstrap stages? I made some
alterations to switch it back to `fldd` when it wasn't supposed to
change, but bootstrap still fails. More investigation required...again.
Rewrote the NEON one's-complement patch and posted it upstream.
Tracked down the cause of the bootstrap failures in my NEON 64-bit
shifts patch: out-of-range shift amounts were not handled leading to
ICEs. Reworked the constant shift handling cases, and resumbitted the
patch for testing. It's failed again. A job for next week.
Summary:
* Multilib test for linaro toolchain.
* Code size test for embedded toolchain.
Details:
1. Multilib test for linaro toolchain.
* Workaround the marm/march=armv5t build by setting the
MULTILIB_DEFAULT to mthumb.
* Investigate how to make multiarch and multilib work together.
Based on current multiarch/multilib patches, it is hard to make them
work together. Trying to set the default multilib dir to the multiarch
dir to workaround it. Need more work to build libgcc.
2. Code size investigation for embedded toolchain.
* Try to test benchmarks.
* Run gcc regression test with –mthumb/-mcpu=cortex=m3/-Os and
analyze the new failed cases. After skipping the cases based on
scan-assembler, warning/error message, etc, there are 5 new failed
cases in three categories:
(1) gcc.target/arm/neon/vst1_lanes64.c: known issue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631
(2) Wrong optimization for gcc.dg/atomic-lockfree.c,
gcc.dg/atomic-noinline.c and gcc.dg/pr30951.c.
(3) g++.dg/eh/filter1.C abort in libsupc++.
Plans:
* Root cause the new failed cases.
* Continue to investigate the multilib/multiarch issue.
Best regards!
-Zhenqiang
Hi Michael,
Spec2000 is now running successfully: there are results at
http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.7%2bbzr114965/logs/armv7l…
However, they seem to have been run in 'train' mode, and none of the
runs are long enough for comparison.
I thought the a9-ref queue was supposed to run in full 'ref' mode?
Andrew
Hi,
OpenEmbedded:
* removed the recipe for building the linux-linaro-3.1 kernel
* add support for the default OE-core kernel
* allows to build the linux-yocto_3.2 kernel for the
qemuarmv7a MACHINE using a vexpress defconfig
* updated the wiki on how to build OE-core with meta-linaro
https://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
* worked OEMetaLinaroCard
* started to talk to CI folks about automating the oe-core+meta-linaro
* wrote a script that automates the process
* ran it on tcserver01 to build the qt4e and sato images against the
source gcc-linaro-4.6-2012.02
Regards,
Ken
