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
Hello Linaro Toolchain Working Group,
linaro-clang-armv8-lld-2stage <https://lab.llvm.org/buildbot/#/workers/140>
has been red since June 7th.
Is anybody looking at the issue?
Thanks
Galina
Progress: (short week, 3 days)
* UM-2 [QEMU upstream maintainership]
- More code review, as softfreeze is now quite close. I think we've
finally got there with the SME patchset (the remaining problems
with v5 were very minor)
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- QEMU-315 OS Lock/DoubleLock work now upstream
-- PMM
Hello,
# Linaro CI's GDB testsuite results
* Implemented new version of change in the Abe shell script to correctly
set auto-load-safe-path so that GDB can load libthread_db.so.1. Since
GDB's configure script needs to be passed an argument containing
literal dollar signs, use '@@' instead of '$' to avoid the shell
misinterpreting it and substitute at the point of use. This version
worked and was merged to the Abe repo.
* Implemented and merged change in the Abe shell script to set variables
pointing to language-specific target tools only if they are present in
the path. This fixes Ada test failures in the GDB testsuite.
* Implemented and merged improvement to our tcwg_gnu-build.sh script to
allow specifying on the command line the Abe repo and branch to use.
# [GNU-767] Support changing SVE vector length in remote debugging
* Analysed and fixed a couple more regressions in my branch.
--
Thiago
Progress:
* UM-2 [QEMU upstream maintainership]
- Code review (misc, plus another round on the SME patchset)
- KVM Forum programme committee work
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- Wrote and sent patches that deal with the last of the "small and
uninteresting" dependencies of the V1 support epic (this one covers
Feat_DoubleLock, which lets guest OSes suppress debug events as
part of their power-down-a-CPU sequence)
-- PMM
Hi guys. I just realized that today's meeting will be right in the middle of dinner
plans. I'll organize better next week. Anyway, here's my status:
- Fourth SME patch set -- parts merged, and some bugs fixed.
- Base/arm-compat portion of semihosting rewrite now upstream.
Target-specific bits for m68k, mips, nios2, xtensa outstanding.
- Almost done with FEAT_HAFDBS (hardware access/dirty updates).
Big changes to ptw.c to make that work: 50+ patches.
The reorg should make FEAT_RME easier though.
r~
Hello,
I just noticed that I didn't send a report for week #24. Sorry about
that. For that reason, this report covers two weeks.
# Linaro CI's GDB testsuite results
* Submitted upstream patch fixing gdb_compile regexp to account for our
GNATMAKE_FOR_TARGET value containing spaces. This should solve the Ada
test failures in our CI.
* Fixed the Abe shell script to correctly set auto-load-safe-path so
that GDB can load libthread_db.so.1. Unfortunately the CI detected a
problem with using the generated manifest to reproduce the toolchain
build, so I'm back to the drawing board on this one.
* Sent a Gerrit change request for the Abe script updating it to use
release 12's branch and tag for GDB and gdbserver, and another one
removing a workaround for a build problem fixed in GDB 9.
* Sent a Gerrit change request for tcwg-dev-build.sh fixing a couple of
issues I found when using it to build and test GDB.
# [GNU-767] Support changing SVE vector length in remote debugging
* Analysed and fixed a couple more regressions in my branch.
# Misc
* Attended a few online sessions from Linaro San Francisco Get Together.
* Sent Gerrit change request updating the TCWG script that generates our
SSH known_hosts file to include the Ed25519 host keys, which are now
preferred in Ubuntu 22.04.
* Was out one day due to “Corpus Christi” public holiday.
--
Thiago
Progress:
* UM-2 [QEMU upstream maintainership]
- First week back after holiday: lots of catchup
- Good progress with the code review queue, including getting
rid of a few things that had been lurking in it for too
long, and another pass through the latest SME series
- KVM Forum programme committee work
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Debugged and fixed a few issues in my code where gdbserver was having
trouble with setting the target description for new threads. Also
fixed regressions in a couple more testcases.
# Linaro CI's GDB testsuite results
* Luis commented on IRC that the GDB testsuite results from the Linaro CI
seemed a bit high with about 540 failures, so I set out to investigate.
The two biggest sources of failures are:
1. Ada tests were failing because they can't build their test
executables. This is expected because we don't have the Ada compiler
in the CI, but normally these testcases would just bail out as
unsupported. Found out that there was a regex in the GDB testsuite
that was (IMHO) too strict for our particular setup and fixed it.
2. All CTF tests are failing. The compiler in the CI seems to be
building test executables with CTF debug info, so we do seem to have a
problem there.
The CI's GDB is also not loading libthread_db.so because of a GDB
security setting, so I fixed that as well and expect some more tests
to pass now.
I still haven't submitted my fixes for 1. to upstream and for the
libthread_db.so.1 issue to our CI scripts because I'm still working
with jenkins-scripts and Abe to reproduce the CI environment to verify
the fixes.
--
Thiago
Progress:
* UM-2 [QEMU upstream maintainership]
- This week was almost entirely code review and similar upstream tasks
- managed to review all the preliminary parts of the SME patchset
- reviewed several other refactoring series from rth
- reviewed a big PS/2 keyboard emulation refactoring patchset
- prep for KVM Forum program committee session
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- FEAT_RASv1p1 and FEAT_DoubleFault now upstream
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Debugged and fixed issues in my code where gdbserver was in some cases
trying to read inferior registers before aarch64_target was fully
initialised, and also while the inferior thread was running. This
improved reliability but there are still some testsuite regressions to
look into.
# Sourceware bug 28561 - [gdb/testsuite] Error due to not reading \r\n
at end of mi prompt
* Posted comment to the bug report summarising my current results.
* Tried to reproduce the bug using the upstream v5.3 kernel (since I was
able to see it with openSUSE Leap's v5.3 kernel), but failed. Still
trying to understand what that implies.
--
Thiago
Progress (covers two half-weeks):
* UM-2 [QEMU upstream maintainership]
- investigating a reported bug with semihosting syscalls over gdbstub
- reviewed a massive series from RTH refactoring our SVE code
in preparation for handling SME
* QEMU-422 [QEMU Arm Neoverse V1 vCPU for TCG]
- looking at exactly what FEAT_RASv1p1 and FEAT_DoubleFault require
of a minimal RAS implementation like QEMU's
- sent a patch implementing FEAT_RASv1p1 (a no-op for QEMU)
- sent a patch implementing FEAT_DoubleFault (turns out to be
simpler than I initially feared it might be)
-- PMM
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
* Found out that one issue I was having with gdbserver was caused by an
incompatibility it has with zsh (sourceware bug 26116).
* Fixed a gdbserver crash in my code where a register set was NULL in
the target description.
* Now working on an issue where the target description says SVE isn't
supported, but the regsets information says they are. This is caused
by my code sometimes moving the first ptrace call to get the inferior
registers to a time before it is properly stopped.
# Sourceware bug 28561 - [gdb/testsuite] Error due to not reading \r\n
at end of mi prompt
* Set up a few containers and KVM guests to attempt to reproduce this
bug on different environments. Reproduced it successfully on an
openSUSE Leap 15.3 guest, as well as Ubuntu 20.04 and 22.04 containers
in said guest. I wasn't able to reproduce on Ubuntu 20.04 nor 22.04
guests. Suspecting it's a kernel issue where the fix was backported to
the Ubuntu kernels.
--
Thiago