== Progress ==
* Meetings and Misc (3/10)
- Upgraded my Samsung Chromebook to boot Ubuntu trusty instead of
using crouton. Works much better for native builds now.
* Worked on perfecting building binary tarballs in a 32bit chroot
that run on any platform. (TCWG 383 - 7/10)
- Added zlib to infrastructure so libz.so.1 can be found at runtime.
- Force libgloss to build for bare metal.
- Fixed minor issues with Canadian cross builds.
== Plan ==
* Figure out why Canadian cross builds fail on the TCWG build farm,
but work on my local machines.
* Continue improving building binary releases.
* Get D01 board setup and working.
* Get back to test result verification automation.
- rob -
== Progress ==
* GDB arm v8 record/replay
-- Support for recording advance SIMD load store instructions.
[TCWG-403] [4/10]
-- Code cleanup and patch creation. [2/10]
-- Investigation of patches failing in native configuration. [TCWG-484] [2/10]
* Miscellaneous
-- Sick day off on Monday [2/10]
== Plan ==
* GDB arm v8 record/replay
-- Bug fix issues stalling patch submission upstream.
-- Submission of patches upstream.
-- Bug fixing to reduce failures.
* Run gdb testsuites on arm/x86 in native/remote for latest feature parity.
* Day out of office on Thursday to collect passport from UK visa office.
Short week (2 days off) (4/10)
== Progress ==
* GCC trunk cross-validation (CARD-647) (2/10)
- reported 2 new compiler build failures and 2 regressions
- tested one proposed patch, which did not fix the regression
- trunk now builds OK again
* Neon intrinsics tests (1/10)
- cleaned branch to prepare submission
- working on Cumulative Saturation Neon flag support for AArch64
* aarch64 libsanitizer support
- resumed work: libsanitizer no longer builds with recent glibc,
will need to patch it upstream before bringing it back to GCC.
- testing will be difficult using qemu since libsanitizer reserves a
huge chunk of memory at startup (8GB) which may not be available on
the host machine
* Misc (meetings, conf-calls, ....) (3/10)
- 1:1 calls, weekly calls
- backports review
== Next ==
* GCC trunk cross-validation:
- test Kugan's patch before submission
- evaluate effort to develop a mail-driven support for testing
patches vs trunk befiore submission
- add support for validation of FSF-4.9 branch
* Neon intrinsics tests
- add support for Cumulative Saturation Neon flags on AArch64
* AArch64 libsanitizer
- discuss how to make cross-testing more practical
Short week (3 days)
== Issues ==
* None
== Progress ==
* CARD-1162 : Linaro GCC 4.9 and CARD-1355 : stabilization and
optimization effort for ARMv8-a (4/10)
- Enhanced my backporting script
- Looked at the merge process (4.9, 4.8 and 4.7 merge are comming)
- 40 backports stiil need validation
* Misc: (2/10)
o Various meetings.
o Discussed schroot testing
== Next ==
* FSF branch merges
* Document backporting script usage
* Continue feedback and help with the validation
== Progress ==
* Zero/sign extension elimination (TCWG-15) (7/10)
- regression tested and fixed all the issues
- final bootstrap and regression testing for arm and x86_64 are ongoing
- will post the patch for comment after checking the results
* benchmarking (TCWG-468) (1/10)
- Set-up chrome-book for a15 release benchmarking
* SAH1 performance (TCWG-413) (2/10)
- Christophe noted regression for aarch64_be due to clean-up patch.
- register_move_cost hook in aarch64 does not handle all the cases
(CORE_REGS and POINTER_REGS) and due to this, it calculates FP2FP cost
for these classes . With CORE_REGS gone, costs for register classes are
now different. Cost table needs adjustment.
* FENV for C11 TCWG-447
- Committed ARM part.
== Plan ==
* Benchmarking.
* Upstream zero/sign extension elimination activities.
* sha1 performance.
== Progress ==
* Kernel (CARD-1246 2/8)
- Fixed edge cases for named registers
- http://llvm.org/PR19841
- http://llvm.org/PR19837
* Background (6/8)
- Code review, meetings, discussions, etc.
- TCWG Rack re-org
- Trying to set up native Chromebooks
- Trying to set up APM
- Trying to add Compiler-RT to our buildbots
== Plan ==
* Continue rack re-org
* Continue RT support on current bots
* Try libc++ bot
* Have a look at sanitizer bot
== Progress ==
* Bank Holiday Monday (2/10)
* Got a postgresql malloc benchmark running (4/10, TCWG-441)
* Started refactoring malloc microbenchmark based on review (2/10, TCWG-160)
* Patch review and testing (2/10)
== Issues ==
* None
== Plan ==
* Holiday Tuesday and Wednesday
* Finish refactoring malloc microbenchmark
* Work on results plotting code for benchmarks
--
Will Newton
Toolchain Working Group, Linaro
Hi,
I've been having this issue with latest binary Linaro 2014.04 toolchain from
http://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-a…
It comes with own sysroot, but linker fails to locate /lib/ld-linux-armhf.so.3
$ make
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o nvs.o nvs.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o misc_cmds.o misc_cmds.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o calibrator.o calibrator.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o plt.o plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o wl18xx_plt.o wl18xx_plt.c
arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o ini.o ini.c
arm-linux-gnueabihf-gcc -L/tmp/lib/ nvs.o misc_cmds.o calibrator.o plt.o wl18xx_plt.o ini.o -lm -lnl-3 -lnl-genl-3 -o calibrator
/opt/linaro-2014.04/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/ld-linux-armhf.so.3
collect2: error: ld returned 1 exit status
Makefile:26: recipe for target 'all' failed
make: *** [all] Error 1
And when I pass my own sysroot, it works fine.
Is it supposed to work as a standalone toolchain with its own bundled sysroot?
Thanks.
--
Denys
I've been digging through test logs, and for gcc 4.9.1 native x86_64
tests, all the libsanitizer test cases fail to link due to unresolved
symbols from libpthread and libdl. Does anybody know more about this
bug, or care to fix it ? :-) It still exists in gcc trunk.
- rob -
== This week ==
- Completed GCC Launchpad bug dispositions [CARD-300][2/10]
- Backported PR61202 - gcc generated invalid sqdmulh instruction
[TCWG-485](2/10)
- Triaged and investigated Launchpad bug 1295738- Unable to find a
register to spill in class 'LO_REGS' [Card 300](3/10)
- Triaged and investigated Launchpad bug 1248752 - ARM assembly
instruction compile error [Card-300](3/10)
== Next week ==
- Resolve Launhpad bugs 1295738 and 1248752
- Triage and investigate other bugs as time warrants
== Future ==
No Plans.
== Planned holidays ==
No Plan
== Progress ==
* Worked on building binary tarballs from Jenkins. (TCWG 383 - 4/10)
* Continuing work on regression test analysis and reporting. (TCWG
448 - 3/10)
- now copying the check.log from make check to toolchain so
tcwgweb.sh can scan it for build errors in the test cases.
- Got the delimiter for concurrent Jenkins builds changed, now
glibc build problems are gone.
- Track down and try to fix testsuite build issues.
* Meetings and Misc. (3/10)
- Worked on making remote testing go faster. Setting
ControlPersist seems to help.
- Much debugging of Jenkins related issues.
== Plan ==
* Continuing work on validating test results and fixing testsuite
build issues. (TCWG 448)
* Probably more work on binary tarballs. (TCWG 383)
* More tracking down and fixing Jenkins related issues.
== Issues ==
* For some reason libgloss isn't getting built for *-elf via
Jenkins/Cbuildv2.
Hi,
I have tried out a prototype of using binfmt_misc, and it does not appear to be a worthwhile solution at this point.
Bottom line: with a nice fast multi-core x86 server and a pool of ARM boards we can test GCC in ~20min.
Testing setup:
- Core i3 2-core host
- Chromebook 2-core target, SSD disk
- WiFi network
- GCC mainline built from sources with same flags both natively and cross: C, C++, Fortran.
General observations about testing ARM toolchains:
- When testing natively target is busy 100%: around 50% of time is spent compiling testcases, 40-45% in dejagnu/expect, 5-10% on actual test execution. Target is the bottleneck.
-- 21633.22user 4400.13system 4:13:11elapsed
- With testing cross using standard rsh_prog=ssh, rcp_prog=scp, target is busy 40% of the time: 30% on ssh, 10% on actual test execution. Host is the bottleneck.
--
- When testing cross (using method below) target is busy only 15-20% of the time: 10% on ssh and 10% on actual test execution. Host is the bottleneck.
-- 9490.16user 2882.54system 1:10:57elapsed
I've got a prototype implementation of parallelized cross-testing of GCC that I'm happy with using rsh_prog and rcp_prog dejagnu wrappers:
General observations on dejagnu cross-testing process:
- All communication with the target is done by Dejagnu via rsh_prog and rcp_prog hooks. These are normally defined to ssh and scp respectively.
- Dejagnu copies every testcase to /tmp/ on the target with scp.
- Dejagnu executes every testcase via ssh off target's /tmp/. In total there is 1 scp and 3 ssh invocations per testcase.
The idea of below scripts is to assume shared filesystem between host and a pool of target boards, and skip copying executables to target's local filesystem. Since there is no longer local state (local state == contents of /tmp) on the target boards, testcases can be executed on any of the boards in the pool. This happens transparently to dejagnu: dejagnu issues "rsh_prog chromebook-pool ./test" and then rsh_prog converts this to "ssh chromebook-XX ./test", where XX chosen at random.
Script implementation notes:
- For some unholy reason there is no way of correctly parse command line from dejagnu and give it to bash. The reason why myssh script ssh'es onto host itself is because that's the only way I've found to reliably execute the command. Hey! The command line was intended for ssh anyway!
- Myssh script translates hostname of foobar-pool-01-03-08 into foobar01, foobar03 or foobar08 chosen at random. If there is no "-pool-" mentioned in hostname, then it is used verbatim.
--
Maxim Kuvyrkov
www.linaro.org
== Progress ==
* GDB arm v8 record/replay
-- Completed implementation of system call recording [TCWG-409] [4/10]
-- Support for recording A64 Loads and stores [TCWG-409] [2/10]
-- Bug Fixing to reduce failures in gdb.reverse testsuite [TCWG-484] [2/10]
* Miscellaneous
-- Day off on Friday [2/10]
== Plan ==
* GDB arm v8 record/replay
-- Submission of patches upstream.
-- Bug fixing to reduce failures.
-- Advance SIMD load/store instruction recording support.
== Issue ==
* None.
== Progress ==
* Investigate PR61220, 61225 and 61278, which are triggered by my
previous commits. Patches are in review. (9/10)
* Investigate codes generated by shrink-wrapping interrupt routes. It
seams no dwarf info issue.
* Misc update for Linaro crosstool-ng to make the build work in case
someone wants to use it.
- Down grade gdb to 7.6.
- Disable multilib for 4.9.
- Move local patches at binutils/linaro-2.24.0-2014.03 to
binutils/linaro-2.24.0-2014.05.
== Plans ==
* Push pending patches.
== Planed leaves ==
* June. 2.
Hi,
I've run into some compile errors after updating to 4.9 -- usually getting
undefined references to symbols defined in helper static libraries.
It turns out this is triggered by gcc -flto now creating slim object files
by default (-ffat-lto-objects "fixes" it) - but I think it is actually an
ld bug that should be fixed at some point. ld (regardless of whether I use
-fuse-linker-plugin, -fuse-ld=gold or -fuse-ld=bfd) doesn't seem to see LTO
bytecode in object files that are inside an ar wrapper.
It deals with the library just fine if I use "ar x" to extract its object
files and link to them individually as opposed to the .a file.
I've attached a small test case to demonstrate ("make broken" shows the
error, "make works" shows the workaround).
Is there any reason why ld should behave the way it does, or is this a bug
that needs fixing?
ttyl
bero
== Progress ==
* Reload - IRA bug fix (3/10)
Not able to reproduce in trunk, r210538 masks the bug again :(
Discussed with maxim on extending the macro ,Likely spilled class for thumb2.
Decided that it will lead to performance regressions. Conservative fix
is to allow the pattern for ARM target alone. Verfying the fix by on
armhf schroot
* Testing GCC Linaro compiler on Hardware (4/10)
Completed GCC Linaro compiler 4.8 and 4.9 correctness tests on
hardware. Completed running SPEC 2006 for -O3. Completed running
SPEC2006 for -O3 -ftlo and -mcpu=cortex-a57. Triggered PGO runs on
hardware.
Looked at bootstrap failure with BOOT_CFLAGS="-mcpu=cortex-a57".
Changed from system assembler to Linaro assembler solved it as system
assembler is old.
* Misc (3/10)
- Completed installing ubuntu, set up chroot and migrate to toolchain
64 environment. (2/10)
- 1-1 meetings (Ryan, Christophe and Maxim) (1/10)
- AMD internal support work and meetings
== Plan ==
* Continue bug fixing.
* LTO bootstrap failure
* Testing GCC Linaro compiler on hardware.
* UK VISA processing.
== Issues ==
* None
== Progress ==
* CARD-1162 : Linaro GCC 4.9 and CARD-1355 : stabilization and
optimization effort for ARMv8-a (8/10)
- Looked at Jenkins build/failures/reportin
- Review the backporting process and scripted it
- 40 backports are in review and need validation
* LP #1169164 : including signal.h exposes various PSR_MODE #defines
- Committed upstream.
* Misc:
o Various meetings (2/10)
o LCU'14: Register and booked flights
== Next ==
* Child care today
* Improve the backport script and document it's usage
* Continue backports
* Continue feedback and help with the validation
== Progress ==
* GCC trunk cross-validation (4/10)
- build broken last week-end, because of a
new optimization that broke glibc build.
- glibc fixed by Joseph mid-week, updated
- to help diagnose build failures earlier, I have setup
a reduced version of the validation framework,
which only performs a build of binutils+glibc+gcc,
at every commit on gcc trunk for 16 arm+aarch64
configurations. [ yes, another buildbot of sorts ]
- restarted builds+validations to last known successful
status (i.e. before last week-end)
- builds are catching up
* Neon intrinsics tests (3/10)
- continuing conversion (about 40 files done, out of ~140)
* Misc (meetings, conf-calls, ...) (3/10)
* Backports for 4.9:
- started reviewing candidate backports
== Next ==
* GCC trunk cross-build/cross-validation:
- monitor and report regressions
* Neon intrinsics tests:
- continue conversion
- prepare a cleaner branch for upstream submission
* Backports:
- more reviews
- process improvements
== Progress ==
* Kernel (CARD-1246 4/10)
- Named registers committed in Clang
- GCC seems to break on local named regs, too.
- Trying to change the kernel code to use only globals for non-GPRs
- Adding support for pointer types, and structure fields in GNRVs
* Benchmarks (CARD-716 0/10)
- Re-enabling perf reports for LNT bot (ARM fixed reporting)
* Background (6/10)
- Code review, meetings, discussions, etc.
- Removing *all* buildbots' batteries after failure
- Testing D01 box, not stable yet for toolchain testing
- Moving development to git.linaro.org (for backup)
- Planning TCWG rack migration
- Drafting an LLVM white paper
== Plan ==
* Continue with named register extra work (http://llvm.org/PR19837)
* Start TCWG rack migration
* Discussions about LLVM white paper
== Progress ==
* Investigate and fix building glibc for ARM with -mtls-dialect=gnu2 (3/10)
* Investigate ld TLS behaviour for Huawei (1/10)
* Refactor scripts to enable benchmarking postgresql malloc
performance (2/10, TCWG-441)
* Patch review and testing (1/10)
* Diagnose and fix glibc testsuite failures on aarch64 (2/10)
* Meetings, admin (1/10)
== Issues ==
* None
== Plan ==
* More malloc application benchmarking
--
Will Newton
Toolchain Working Group, Linaro
== Progress==
lowlevellock performance bugs - TCWG-435 [5/10]
* Tried various methods to build/test glibc for aarch64
* Eventually succeeded (tests passed)
cbuild benchmarking - TCWG-360 [3/10]
* cbuildized spec2xxx scripts working as far as 'run'
Meetings/mail/etc [2/10]
== Plan ==
Holiday for one week
After that:
* Clean up cbuildized spec2xxx scripts, cbuildize them some more &
discuss with Rob
* Send lowlevellock patch upstream
* If time, put together some more experimental memset implementations
I have been thinking how to simplify cross-testing our toolchain for both automated and development/debugging builds, and among various options the most universal I came up with is ARM hardware + ssh + binfmt_misc + sshfs. I wonder if anyone has already tried this or can suggest alternatives which are as universal.
Given:
- host x86_64 development machine
- cross-compiler
- target hardware with fast network to the host
- host and target have ssh
- testsuite (gcc/glibc/gdb/etc)
Here is how it is going to work
1. On host we create a simple wrapper script that will pass through its arguments as command to execute on target via ssh:
===
#!/bin/sh
ssh -p 22NN $TARGET_BOARD "$@"
===
2. We register this script in binfmt_misc to be used as interpreter for target binaries. Value of $TARGET_BOARD will be picked up from the environment and can be set to different boards for different testsuite runs.
3. The target board needs to be prepared for a particular testsuite run:
-- Runtime libraries need to be either copied or mounted via sshfs from the host. It is an open question how best to install several sets of libraries (for parallel runs) so that each set appears to be main system libraries. My current thinking is a separate ssh server inside chroot per each test run.
-- Test directory needs to be sshfs mounted on target from host so that the target could see test executables.
-- Preparation/finalization of the board can either be done explicitly before/after testing. Or it can be done on demand by the aforementioned script: the script checks whether a multiplexed ssh socket exists, and, if not, it prepares the board and starts a multiplexed ssh connection.
4. Testing is fired up as if it is normal "native" testing. Whenever kernel is given an ARM binary to execute -- it passes it off to wrapper, which passes it off to the target board via ssh. The board sees same filesystem as host and happily executes binaries against toolchain runtime libraries.
Comments or rotten tomatoes?
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
= Progress ==
* Worked on the LLVM branch of Cbuildv2 (TCWG - 1/10).
* More work on regression test analysis and reporting. (TCWG 448 - 5/10)
* Meetings and Misc (4/10)
- Produced lots of test results via Jenkins, need to verify
they're not having remote target problems.
== Plan ==
* Verify test runs aren't having problems with remote targets.
* Start training the Jenkins Failure Analysis plugin.
* Install lava-tool and get it working on all the tcwgbuild* machines.
* Continuing work on regression test analysis and reporting. (TCWG
448 - 5/10)