Hello,
I noticed that I didn't send a report for week #30. Sorry about that. For
that reason, this report covers two weeks.
# [GNU-767] Support changing SVE vector length in remote debugging
- Prepared and submitted upstream a fix and a testcase for a small SVE bug
when debugging in native mode an inferior which changes the SVE length.
Luis reviewed it and I submitted v2 addressing his comments.
# Misc
- Was out for 2 days.
--
Thiago
Progress:
* UM-2 [QEMU upstream maintainership]
- more investigation, triage and fixing of minor bugs in run-up to release
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- starting working on the PMUv8p5 enhancements. These consist of a couple
of new cycle-counter-disable bits (easy) and extension of the event
counters to 64 bits (more tricky). So far I have code for the easy part
and have made a start on the hard part...
-- PMM
Progress:
* UM-2 [QEMU upstream maintainership]
- debugged and sent patch to fix a bug in timer_create
syscall support in linux-user on certain host libcs
- tried and failed to repro a bug where semihosting SYS_HEAPINFO
was returning addresses in the flash rom
- more Coverity issue triage -- now have finished triage of
everything that isn't either in the test suite or an
"insecure data handling" issue. Sent patches for a few
issues, prodded other people about some more...
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Fixed last bug which prevented the sve-ioctls QEMU testcase to be
correctly stepped through in gdbserver. The next step is checking
whether any regression was introduced by my changes, and clean up the
code.
* In the process, spotted small bug in GDB when stepping through the
sve-ioctls QEMU testcase using the existing native support. Started
preparing a patch to submit upstream.
# [LLVM-769] Linaro CI
* Increased tcwg-fx-02 ccache max size to 40 GB.
* Learned a bit about Zorg and started adding “depends_on_projects”
field to builders running on Linaro workers.
--
Thiago
Hi,
I noticed that bots like flang-aarch64-latest-gcc are quite slow and could
benefit from enabling ccache. Could you make it available on the system so
it could be turned on for all these builds?
Thanks,
--
Mehdi
Progress:
* UM-2 [QEMU upstream maintainership]
- softfreeze this week; lots of pullrequest merging
- spent some time going through our backlog of Coverity Scan issues, triaging
them and sending patches for some of them
- sent a patchset fixing portability issues in our configure script which
had crept in recently and were causing problems on OpenBSD and NetBSD
- sent out the invite emails for QEMU Summit
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Rebased the actual SVE vector length changes on top of the stabilised
per-thread target descriptions changes. Now stabilising the result. Fixed
a couple of problems found when remote-debugging QEMU's sve-ioctls test
binary, currently looking into a third one.
# Linaro CI's GDB testsuite results
* Updated and expanded the LLVM Docker Buildbot Maintenance wiki page with
the information about ccache setup I gathered in the past few days. Also
added a link to it to the Buildkite Bot Maintenance wiki page since
libstdc++ buildkites uses the same configuration.
* Increased ccache max size in GNU build jobs on tcwg-jade-02.
* Updated ABE repo's tested branch with my commits from last week to
improve the GDB testsuite results. Confirmed that the GDB testsuite went
from 538 unexpected failures to 307. There's still room for improvement
though.
--
Thiago
Progress:
* UM-2 [QEMU upstream maintainership]
- took over pullreq handling from RTH for the next couple of weeks
- wrote and sent patches that fix a mishandling of Secure stage 2
translation caused by QEMU not noticing that some config bits are
in VTCR_EL2 and some in VSTCR_EL2. Removed an ancient microoptimization
that was getting in the way of fixing that.
- sent patch fixing incorrect syndrome value for data abort on some
post-indexed load/store insns
- RTH's SME patchset is now upstream, so now would be a good time to
test it if anybody has compiler test cases or similar they were
thinking of running under QEMU
- softfreeze next Tuesday: started reviewing and collecting up
minor patches for a pre-freeze pullreq
-- PMM
Hello,
I went through the LLVM build bots (and also the libc++ buildkites) and
increased their ccache max size. There was a big impact on the flang
builds on tcwg-jade-01 (which went from 1h–2h to 10min–30min), but not
on other builds. One reason is probably that since I made this change
earlier today, there wasn't time yet to finish enough several-hours-long
builds to warm up the caches.
Since different machines have different disk sizes and free space I
chose different ccache max sizes for them, as follows:
* tcwg-fx-02 hosts the following build bots:
- clang-aarch64-sve-vls-2stage
- clang-aarch64-sve-vls
- clang-aarch64-sve-vla-2stage
- clang-aarch64-sve-vla
All share the same ccache. I changed its max size to 20 GB. It's not a
lot, but this machine is also used as a dev box so I though it would
be good to preserve a fair amount of space.
* tcwg-jade-01 hosts the following build bots:
- clang-armv8-lld-2stage
- clang-armv7-vfpv3-2stage
- clang-armv7-global-isel
- clang-armv7-quick
- clang-armv7-2stage
- clang-armv7-lnt
- flang-aarch64-latest-gcc
- flang-aarch64-rel-assert
- flang-aarch64-release
- flang-aarch64-latest-clang
- flang-aarch64-debug
- flang-aarch64-out-of-tree
- flang-aarch64-sharedlibs
- flang-aarch64-dylib
- clang-aarch64-full-2stage
- clang-aarch64-global-isel
- clang-aarch64-lld-2stage
- clang-aarch64-quick
All armv7 and armv8 bots share one ccache, and all aarch64 bots share
another. I changed the max size of each one to 100 GB.
* tcwg-jade-04 hosts the following build bots:
- lldb-aarch64-ubuntu
- lldb-arm-ubuntu
- buildkite-linaro-armv8-libcxx-01
- buildkite-linaro-armv8-libcxx-02
- buildkite-linaro-armv8-libcxx-03
- buildkite-linaro-armv8-libcxx-04
The buildkite bots share a 50 GB ccache, while lldb-arm-ubuntu uses
another 50 GB ccache due to being based on a different distro version.
And lldb-aarch64-ubuntu also uses its own 50 GB ccache.
* tcwg-llvmbot_tk1-01.tcwglab hosts the following build bot:
- silent-linaro-tk1-01
I changed the max cache size to 10 GB. There's not a lot of free space
on the machine.
* tcwg-llvmbot_tk1-03.tcwglab hosts the following build bot:
- normal-linaro-tk1-02
I changed the max cache size to 20 GB.
* tcwg-llvmbot_tk1-05.tcwglab hosts the following build bot:
- silent-linaro-tk1-08
I changed the max cache size to 10 GB.
* The following tcwg-llvmbot_tk1-* machines are currently unreachable so
I couldn't examine them:
- tcwg-llvmbot_tk1-02.tcwglab
- tcwg-llvmbot_tk1-04.tcwglab
* The following tcwg-llvmbot_tk1-* machines are running an llvmbot
container but no builder container, so I didn't change their ccache
configuration:
- tcwg-llvmbot_tk1-06.tcwglab
- tcwg-llvmbot_tk1-07.tcwglab
- tcwg-llvmbot_tk1-08.tcwglab
- tcwg-llvmbot_tk1-09.tcwglab
* tcwg-jade-02 is a GNU builder, and from peeking into a few containers
running build jobs I have the impression that it doesn't use ccache.
Should I look into it?
* Going through our ssh config file I didn't find these build bots that
are listed at http://llvm.validation.linaro.org/ so I didn't check
their ccache usage:
- clang-arm64-windows-msvc-2stage
- clang-arm64-windows-msvc
- clang-arm64-windows-msvc-2stage
- clang-arm64-windows-msvc
- clang-native-arm-lnt-perf
- clang-armv7-vfpv3-full-2stage
- clang-thumbv7-full-2stage
- libcxx aarch64
- libcxx aarch64 -fno-exceptions
--
Thiago
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Analysed and fixed a couple more regressions in my branch. The change to
per-thread target descriptions in gdbserver (which was the more
challenging part) is now free of regressions. Now cleaning up the part
that actually deals with the SVE vector length change.
# Linaro CI's GDB testsuite results
* Increased ccache's max size on most build bots. Sent email to the
linaro-toolchain list summarising the current status of their ccache
setup.
* Started looking more closely into how ccache configuration is put
together in our container scripts to document it on the wiki (together
with the steps I took to change the ccache max size).
--
Thiago
