== 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)
== Progress: ==
Holiday [2/10]
Rewrite of division optimisation changes following review - TCWG293 [8/10]
== Plan ==
Mostly on holiday this week. I may be working sporadically
Back full time
== Progress ==
* resumed 1:1 calls with Zhenqiang, Venkat, Charles.
* GCC trunk cross-validation (2/10):
- monitored results
- a few improvements/cleanups
* Neon-intrinsics tests (5/10)
- continuing conversion
- needs to add support AArch64 Neon overflow flag
* Misc (meetings, conf-call, ..) (3/10)
* Successfully tried OpenNX setup put in place by Maxim
(on office computer, despite firewall and no root access)
== Next ==
* GCC trunk cross-validation:
- monitor and report results
- use this system to pre-validate a patch from Kugan
- share scripts with Kugan
* Neon intrinsics tests:
- continue conversion
- hopefully push a preliminary version upstream
== Progress==
lowlevellock performance bugs - TCWG-435 [3/10]
* Trying to build/test aarch64 on a foundation model
cbuild benchmarking - TCWG-360 [4/10]
* Integrating Maxim's spec scripts into Kugan's benchmarking branch
* Began modifying the branch to use existing cbuild functions where possible
Meetings/mail/etc [3/10]
== Plan ==
Holiday next week (w/c 26th May)
This week:
* Try testing glibc on system qemu rather than foundation model
* Carry on with cbuild benchmarking
* If time, put together some more experimental memset implementations
