== Progress ==
Bug#403/#418/PR63870 [7/10]
. Prepared patches for vldN_lane/vstN_lane
. reviewed related patches on list
. code changes are ready, but reveal errors in the testsuite
Misc [3/10]
. mailing llists
. meetings
. some help with lab config with Renato
= Progress ==
* TSAN support for Aarch64 (6/10)
* Emails, linaro/AMD status meetings. (4/10)
1-1 with maxim, Christophe.
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
== This week ==
* GCC Modularization Project (9/10)
- Flattening header files
- tree-core.h, and tree.h, c-common.h
- Completed
- Bootstrap successful on x86
- Testing in progress on all platforms listed in config-list.mk
- Reviewed and tested patches from Prathamesh
* Misc (1/10)
- Conference calls
== Next week ==
- Submit tree.h and related patches for review
Hi all,
I've asked ITS to install a git post-commit hook to send an email
after commits in the toolchain git repos.
It turns out that they prefer to send such email to mailing-lists, to
avoid having to maintain the list of recipients themselves, which of
course really makes sense.
So far, we already have a cbuild2 mailing-list for commits, which Rob
asked to now point to abe instead of cbuild2 repo.
I was thinking about asking a single new mailing-list (eg
tcwg-commits) and send commit emails to that list for all ours repos,
instead of having a list per repo to which interested team members
would have to subscribe.
We currently have the following git repos:
abe
backflip
backport-tools
binutils-gdb
binutils
cbuild2
cortex-malloc
cortex-strings
cross-build-tools
dejagnu
dmucs
eglibc
fakebench
gcc-new
gcc
gdb
glibc
lavabench
newlib
release-notes
spec2xxx-utils
tcwg-sysadmin
Any objection to having such a list?
(I do not plan to force subscription of any of you :-)
Christophe.
== Progress ==
* Automation Framework (CARD-1378 5/8)
- Re-adding Junos and D01s to the rack
- Planning access from remote servers
- Following up new rack setup
- Moving lab bridge to a VM
- Re-checking all boards for stability
- Working on the dragon boards to get them stable
* Background (3/8)
- Code review, meetings, discussions, etc.
- Trying to get the LLVM Perf system back online
- Multiple bot breakages
- Reviewing patches for 3.5.1 release
- Jira farming
* 1 day off
== Plan ==
* Continue working on the dragon boards
* Try to get an internal ARM64 buildbot
* Hopefully finish off the lab move
== Progress ==
* GCC trunk/4.9 monitoring (2/10)
- still tracking cause of random "interrupted system call" errors
- checked possible regressions
* AArch64 sanitizers (1/10)
- managed to build on board, didn't try to run the tests yet
* Neon intrinsics tests (2/10)
- fixed a couple of bugs in the already upstreamed tests
- continued conversion to GCC testsuite
- support to external user (LLVM based compiler)
* 4.9-2014.12 release (1/10)
- backports+branch reviews
* Misc (4/10)
- meetings, conf-calls, emails....
== Next ==
* GCC trunk/4.9 monitoring
* AArch64 sanitizers
* Neon intrinsics tests
* cbuild2/abe: look at backport and tcwgweb
Holidays: Dec 22nd - Jan 2nd
Apology for sending this out late.
== Progress ==
Debugging ARM gdb watchpoint failures [4/10] [TCWG-567]
-- Prepared a testsuite patch for unsupported tests on ARM
-- Investigation of other failures due to watchpoints installation
rejected through ptrace interface.
QEMU kernel debugging setup [4/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
Studying arm debug unit architecture versions for possible upgrade to
watchpoint/hwbreak implementation. [1/5] [TCWG-569]
Miscellaneous [1/10]
-- Meetings, Emails etc
-- Follow up on Hong Kong Visa
== Plan ==
Figure out unexplained arm gdb watchpoint rejection from ptrace interface.
More work to figure out a way to debug arm Linux kernel using QEMU
Some further study on arm debug unit architecture versions.
