== Progress ==
QEMU kernel debugging setup [5/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
GDB with cygwin build/testing process [2/10]
-- Figured out GDB build and test procedure on cygwin.
Miscellaneous [3/10]
-- Meetings, Emails etc
-- Hong Kong visa application: re-submission of application.
== Plan ==
QEMU kernel debugging setup [TCWG-568]
-- Try to figure out kernel debugging help for ptrace debug
GDB with cygwin build/testing process
-- Document cygwin gdb work flow
-- Buid arm-remote gdb on cygwin
-- Identify gdb-remote issues on a cygwin host if any
== This week ==
* GCC modularization project
- Fixed df.h flattening patch to build on all targets in config-list.mk
- Flattening expr.h patch in progress.
== Next week ==
- complete expr.h patch
- Submit df.h flattening patch to gcc-patches for review
- Test cfgloop.h flattening patch on all targets with ISL enabledin
config-list.mk and submit to gcc-patches for review.
Holiday [6/10]
Misc [3/10]
* Mail backlog
* Moved all current AArch64 work off 'my' Juno, as ARM needed it back
* A little bit of a look at another possible memcpy performance issue
libm exercising - TCWG-558 [1/10]
* Reduced 'needless calls to pow' to a simple test case
** Found that this is actually an all-targets thing (at least AArch32,
AArch64, x86)
* Looked through benchfft output
** Looks like only one implementation calls libm much
** This is probably just bad code, but could do with a comparison run
on non-AArch64 to be sure
=Plan=
Switch to TCWG Junos
Think about where to go next with libm exercising
Complete 'same network' workaround, test benchmark repeatability
Port benchmarking scripts to ABE repo
Get storage/automation started, if Rob has time
=Absences=
On holiday Monday 22nd Dec to Friday 2nd Jan
== 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
