Hi,
You are receiving this email because you are listed as the owner for at least one LLVM build slave on http://lab.llvm.org:8011/buildslaves <http://lab.llvm.org:8011/buildslaves>.
This message is a heads up concerning the upcoming upgrade of CMake discussed here: http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html <http://lists.llvm.org/pipermail/llvm-dev/2020-March/140349.html>. As discussed on that thread, LLVM will require CMake 3.13.4 in order to build after the release branch for LLVM 11.0.0 is created. Using an older CMake will be an error.
In order to keep things running smoothly, we would greatly appreciate if you could upgrade CMake on your builder(s) to at least CMake 3.13.4 before the next release branch is created. Please reply privately to this email when you've done so -- this will allow keeping track of who has and has not upgraded.
Thank you and have a wonderful day,
Louis
Short week (4 days)
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
- still looking at improving MVE tests to avoid failures in several
non-supported configurations. No satisfactory solution so far (there
are always combinations of GCC configure option and validation-time
options that are incompatible and produce failures instead of
unsupported)
- maybe we should agree on a common way of running the testsuite
* GCC:
- PR94743 (IRQ handler and Neon registers): sent a patch to emit a
warning. More ambitious patches would be too intrusive for stage 4.
* FDPIC/GDB:
- no progress this week
* misc:
- infra fixes / troubleshooting / reviews
- started looking at cortex-m benchmarking harnesses
== Next ==
* FDPIC GDB
* GCC/cortex-M
* cortex-m benchmarking
== Progress ==
* Morello
- Finished capability formatting
- Got a couple cosmetic patches in review
- Also reviewing needed ptrace support
== Plan ==
* More Morello
[VIRT-349 # QEMU SVE2 Support ]
More progress on insn implementation.
More patches from Stephen Long merged.
More good review from Laurent Desnogues.
Down to perhaps 30 insns remaining, and then figuring out some miscomparisons
reported by Laurent, but not diagnosed.
[VIRT-344 # ARMv8.5-MemTag ]
Fixed an exception return bug vs PSTATE.TCO.
[VIRT-327 # Richard's upstream QEMU work ]
Posted some tcg patch sets for 5.1.
Worked on the sparc regression Alex reported vs TEMP_CONST. I've set that
aside for now; I need to come up with a new scheme to debug that one.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- We needed an rc4 (which I wasn't very surprised about), so more
release wrangling again.
- Noticed some bugs in how we set ID registers for the AArch64 'max' CPU;
sent patches (one of which seemed worth getting into rc4)
- There's been a long-standing problem where a linux-user QEMU running
on a 64-bit host and emulating a 32-bit guest can't deal with the
64-bit hash 'offsets' from ext4 getdents, which causes guests using
newer glibc to fail. Linus Walleij wrote a kernel patch which allows
QEMU to request that the kernel gives it hash values that will fit
into 32 bits. I wrote an RFC QEMU patch that would use this and tested
that this does indeed solve the problem. Discussion is continuing on
the kernel size about what the correct API for this is, but the
principle that the kernel should change seems to be accepted.
- A bug was raised that BKPT for arm linux-user wasn't causing SIGTRAP;
sent patches fixing that and some other issues I noticed in that
bit of the code while I was fixing it.
- code review:
+ a patch adding proper FIFO emulation to the PL011 UART model
+ rth's patchset improving codegen of neon integer-compare-vs-0 insns
+ xilinx patchset to disable unsupported FDT firmware nodes
+ patchset adding kaslr-seed properties to the virt board dtb
(mostly useful for OP-TEE)
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Progress with neon decodetree conversion. I've now completed all
the 3-reg-same insn grouping, which is a large enough amount that
I'm planning to send out a patchset with what I have so far.
Need to refactor/tidy up some bits of the code first, now I can
see what the completed conversion looks like.
thanks
-- PMM
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- Committed a few fixes to MVE/CDE tests to avoid failures on
arm-linux-gnueabi toolchains
- Sent a few more testcases fixes
- PR94538 (pure-code/M23): Let Wilco handle it since he has more testcases
- Looked at Linaro bug #5614, and forwarded it for upstream discussion
as PR94743 (IRQ handler and Neon registers)
* FDPIC/GDB:
- rebased gdbserver patches, it still crashes at runtime. Code size
bigger than my last attempt with gdb-8.x.
- tried to link it statically, but that fails because of multiple defs
in uclibc.
* misc:
- infra fixes / troubleshooting / reviews
- lots of disruptions
== Next ==
* FDPIC GDB
* GCC/cortex-M
Looks like there might be something wrong with this buildbot? (none of the
commits seem to have changed lnt - or maybe lnt isn't monitored/blamed in
the buildbot config?)
On Tue, Apr 21, 2020 at 12:16 AM <llvm.buildmaster(a)lab.llvm.org> wrote:
> The Buildbot has detected a new failure on builder clang-cmake-armv8-lld
> while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/3875
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-armv8-01-arm-lld
>
> Build Reason: scheduler
> Build Source Stamp: [branch master]
> c2d86e1f3044abb295796c8267c7b9057f54a067
> Blamelist: Alexander Shaposhnikov <alexshap(a)fb.com>,Chris Bieneman <
> chris.bieneman(a)me.com>,Dan Liew <dan(a)su-root.co.uk>,David Blaikie <
> dblaikie(a)gmail.com>,Johannes Doerfert <johannes(a)jdoerfert.de>,Mircea
> Trofin <mtrofin(a)google.com>,Pavel Iliin <Pavel.Iliin(a)arm.com>,Sam Kerner <
> skerner(a)chromium.org>,Shengchen Kan <shengchen.kan(a)intel.com>,Sriraman
> Tallam <tmsriram(a)google.com>
>
> BUILD FAILED: failed setup lit
>
> sincerely,
> -The Buildbot
>
>
>
>
Short weeks around Easter.
[VIRT-349 # QEMU SVE2 Support ]
Lots of progress on insn implementation.
Several patches from Stephen Long merged. He's coming up to speed nicely.
Some good review from Laurent Desnogues.
Spent some time writing a version of strspn for Arm optimized-routines, as a
way of testing the NMATCH instruction. Found bugs in the tcg optimizer
instead. Still in the process of rebasing the branch upon those fixes, and
upon patch review from Peter.
[VIRT-327 # Richard's upstream QEMU work ]
Couple of patches for 5.0.
[GCC]
Posted v4 of aarch64 cmpti patch set.
r~
VirtIO Related Work ([VIRT-366])
================================
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
VirtIO RPMB ([VIRT-371])
- started work on [vhost-user backend for rpmb]
- have the basic vhost-user loop created, still need to plumb into
QEMU
- will be able to experiment with [VIRT-402] minimal profile once
running
[VIRT-371] <https://projects.linaro.org/browse/VIRT-371>
[vhost-user backend for rpmb]
<https://github.com/stsquad/qemu/tree/vhost-user-rpmb>
[VIRT-402] <https://projects.linaro.org/browse/VIRT-402>
VirtiIO blogpost ([LBO-2])
- wrote up history of VirtIO up to standardisation
- still TODO new work and architectures
[LBO-2] <https://projects.linaro.org/browse/LBO-2>
slides with virtio architectures for Victor
Upstream Work ([VIRT-109])
==========================
- posted [PULL for 5.0-rc3 0/8] a few small fixes (docker, user, pie
and gdbstub) Message-Id:
<20200415104211.9388-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Other
=====
- preparation work and GSoC candidate interviews
[my QEMU developer guide]
<https://people.linaro.org/~alex.bennee/org/presentations/qemu-developer-gui…>
Absences
========
- Home-schooling in mornings
Current Review Queue
====================
* [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com>
Added: <2020-04-09 Thu>
* [PATCH v6 00/36] Initial support for multi-process qemu
Message-Id: <cover.1586165555.git.elena.ufimtseva(a)oracle.com>
Added: <2020-04-06 Mon>
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
--
Alex Bennée
(short week, 3 days)
Progress:
* VIRT-65 [QEMU upstream maintainership]
- getting rc3 out of the door, including sorting out some last
minute bug fixes. As usual, we hope not to need an rc4 but I
expect we will.
- code review; a two-day blitz has got my to-review queue down
to a slightly more manageable size...
+ rth's series refactoring SVE load/store implementation
+ Guenter's i.MX watchdog support series
+ brief pass over raspi USB host controller emulation series
+ patch adding /secure-chosen/kaslr-seed to the virt dtb
+ the Greensocs/Xilinx clock framework patchset
[including doing an editing pass on the docs]
thanks
-- PMM
Hello!
I know, this is probably a very stupid question, but I couldn't find an
answer for it. On the page
https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linu…
there are 3 major download components: gcc/sysroot/runtime.
I download 'gcc', add 'gcc-linaro-.../bin' to my PATH and cross compile my
apps.
On my target system, I need 'libc', and it is present in the
'sysroot-linaro-...'. Do I need to copy all of the contents of
'sysroot-linaro-...' folder to my target? 'linaro-sysroot' folder is kinda
big. 'libc.so' library is 13MB. If there is a way to decrease its size, if
I want to use Linaro compiled programs on an embedded target?
And what is a purpose of 'runtime-linaro-..." component?
Hello!
I know, this is probably a very stupid question, but I couldn't find an answer for it. On the page https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linu… there are 3 major download components: gcc/sysroot/runtime.
I download 'gcc', add 'gcc-linaro-.../bin' to my PATH and cross compile my apps.
On my target system, I need 'libc', and it is present in the 'sysroot-linaro-...'. Do I need to copy all of the contents of 'sysroot-linaro-...' folder to my target? 'linaro-sysroot' folder is kinda big. 'libc.so' library is 13MB. If there is a way to decrease its size, if I want to use Linaro compiled programs on an embedded target?
And what is a purpose of 'runtime-linaro-..." component?
== This Week ==
* LLVM-611 (tune heuristic to lower blx): Working on feedback.
* GNU-659: Doing benchmarking experiments
* Public holiday
- One day off
== Next Week ==
- Continue with LLVM-611 and GNU-659
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are. Updated cmse-15.c test.
Analyzing / bisecting other failures.
- Sent fixes to MVE tests to avoid failures on arm-linux-gnueabi toolchains
- Updated a few bugzilla entries about cortex-m issues
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M
Hi,
clang-cmake-armv7-full fails with "No space left on device", e.g.:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/9808/steps/…
> The Buildbot has detected a new failure on builder clang-cmake-armv7-
full while building llvm.
> Full details are available at:
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-full/builds/9808
>
> Buildbot URL: http://lab.llvm.org:8011/
>
> Buildslave for this Build: linaro-tk1-06
>
> Build Reason: scheduler
> Build Source Stamp: [branch master]
3bc439bdff8bb5518098bd9ef52c56ac071276bc
> Blamelist: Ilya Leoshkevich <iii(a)linux.ibm.com>
>
> BUILD FAILED: failed Checkout test-suite
>
> sincerely,
> -The Buildbot
Could someone please take a look?
Best regards,
Ilya
VirtIO Related Work ([VIRT-366])
================================
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
slides with virtio architectures for Victor
an overview blogpost for Ebba
- started drafting a blog post
Upstream Work ([VIRT-109])
==========================
- posted [PULL for 5.0-rc2 00/13] various fixes Message-Id:
<20200407155118.20139-1-alex.bennee(a)linaro.org>
- a bit of launchpad triage for release
- posted [PATCH for 5.0-rc3 v1 00/11] more random fixes Message-Id:
<20200409211529.5269-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Other
=====
- updated [my QEMU developer guide] for team workshop
[my QEMU developer guide]
<https://people.linaro.org/~alex.bennee/org/presentations/qemu-developer-gui…>
Absences
========
- Easter Weekend (bank holidays)
Current Review Queue
====================
* [RFC][PATCH v2 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1578407802.git.jan.kiszka(a)siemens.com>
Added: <2020-04-09 Thu>
* [PATCH v6 00/36] Initial support for multi-process qemu
Message-Id: <cover.1586165555.git.elena.ufimtseva(a)oracle.com>
Added: <2020-04-06 Mon>
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [PATCH v8 00/74] per-CPU locks
Message-Id: <20200326193156.4322-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
--
Alex Bennée
(short week, 4 days)
Progress:
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Still working through the Neon decoder refactoring. Finished
loads-and-stores and am now on the 2000-line function that handles
data-processing insns...
thanks
-- PMM
Hi,
It looks like several bots assigned to you started failing after e6a39f00e8d0 was committed:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linux-no…http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv8-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux-…
They all fail on the test libcxx/test/libcxx/modules/stds_include.sh.cpp with the following error:
<...>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: fatal error: file '<...>/libcxx/include/type_traits' has been modified since the module file '<TMP>/ModuleCache/1E92AHT/std-1V9DLRO.pcm' was built
#include <vector>
^
<...>/libcxx/test/libcxx/modules/stds_include.sh.cpp:28:2: note: please rebuild precompiled header '<TMP>/ModuleCache/1E92AHT/std-1V9DLRO.pcm'
1 error generated.
Our other bots are not failing, so I very strongly suspect this is not because of the change itself, but rather some weirdness in your bot configuration. For that reason, I will *not* revert the change (that would likely not improve the situation anyway). Can you please collaborate with us to understand and fix the issue?
Thanks,
Louis
Hi,
It looks like the following bots assigned to you started failing recently:
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linuxhttp://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-armv7-linux-no…
The failing tests are all filesystem tests:
FAIL: libc++::assign.pass.cpp
FAIL: libc++::path.pass.cpp
FAIL: libc++::replace_filename.pass.cpp
FAIL: libc++::refresh.pass.cpp
FAIL: libc++::file_size.pass.cpp
FAIL: libc++::file_type_obs.pass.cpp
FAIL: libc++::hard_link_count.pass.cpp
FAIL: libc++::last_write_time.pass.cpp
FAIL: libc++::ctor.pass.cpp
FAIL: libc++::ctor.pass.cpp
FAIL: libc++::increment.pass.cpp
FAIL: libc++::exists.pass.cpp
FAIL: libc++::is_block_file.pass.cpp
FAIL: libc++::is_character_file.pass.cpp
FAIL: libc++::is_directory.pass.cpp
FAIL: libc++::is_empty.pass.cpp
FAIL: libc++::is_fifo.pass.cpp
FAIL: libc++::is_other.pass.cpp
FAIL: libc++::is_regular_file.pass.cpp
FAIL: libc++::is_socket.pass.cpp
Having seen some of these issues before, I strongly suspect this is due to the fact that your builder is running as root. Libc++'s filesystem tests are known to fail when run as root, because some of them need to check for failure to access some files for which there's no permission. This doesn't seem to work when run as root.
Can you work with us to resolve this issue?
Thanks,
Louis
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are.
Spent a long time isolating a regression in CMSE tests. Filed
PR94445 which was then quickly fixed by upstream in ICF optimization.
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M
[VIRT-349 # QEMU SVE2 Support ]
Met with Qualcomm on Friday to discuss sharing the development work, and help
start bringing their new-hire, Stephen Long, up to speed on qemu.
Gave Stephen generic qemu development pointers, and a simple set of SVE2
instruction on which to wet his feet.
[VIRT-327 # Richard's upstream QEMU work ]
Better constant propagation and allocation for TCG.
Worked on probe_guest_base as a follow-up to some of the work Alex was doing
wrt init_guest_space.
Misc patch review for 5.0.
[GCC]
Posted v3 of aarch64 cmpti patch set.
r~
== This Week ==
* LLVM
- LLVM-611 (Tune heuristic for blx): Posted upstream.
- LLVM-612 (Redundant reg moves for 8-bit immediates): WIP patch
* Public Holiday
- one day off
== Next Week ==
- Continue with LLVM tasks
- Start looking at GNU-659
VirtIO Related Work ([VIRT-366])
================================
- minor planning work
- need a few slides with virtio architectures for Victor
- a overview blogpost for Ebba
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
Upstream Work ([VIRT-109])
==========================
- GSoC feedback on proposals
- we have 3 students putting forward proposals for TCG cache plugin
- posted [PATCH] hw/core: properly terminate loading .hex on EOF
record Message-Id: <20200401193849.14017-1-alex.bennee(a)linaro.org>
- posted [PATCH] target/arm: don't expose "ieee_half" via gdbstub
Message-Id: <20200402143913.24005-1-alex.bennee(a)linaro.org>
- posted [PATCH for 5.0 v2 00/10] A selection of sanitiser fixes
Message-Id: <20200401094759.5835-1-alex.bennee(a)linaro.org>
- the linux-user guest map is better targeted at next week
- posted [PATCH v3 for 5.0-rc2 00/12] a selection of random fixes
Message-Id: <20200403191150.863-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [1/1]
=======================
[PATCH for-5.0 v3 0/7] configure: Improve PIE and other linkage
Message-Id: <20200327220353.27233-1-richard.henderson(a)linaro.org>
Absences
========
- Splitting time between work and home-schooling
Current Review Queue
====================
* [PATCH v4 00/10] tests/vm: Add support for aarch64 VMs
Message-Id: <20200312142728.12285-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [PATCH v8 00/74] per-CPU locks
Message-Id: <20200326193156.4322-1-robert.foley(a)linaro.org>
Added: <2020-03-27 Fri>
* [virtio-dev] [RFC PATCH] virtio-iommu: Add PAGE_SIZE_MASK property
Message-Id: <20200323133831.2110014-1-jean-philippe(a)linaro.org>
Added: <2020-03-27 Fri>
* [virtio-dev] [PATCH v2 00/10] virtio-mem: paravirtualized memory
Message-Id: <20200311171422.10484-1-david(a)redhat.com>
Added: <2020-03-27 Fri>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- More freeze related wrangling...
* VIRT-241 [QEMU ISA Support for A-profile]
- pushed the ARMv8.2-TTS2UXN patchset out to the mailing list
- found and fixed a bug in our PAN support where we were making
PSTATE.PAN forbid execute access, not just data access
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- Started on some preliminary refactoring that we'll need so we can
more conveniently modify the decoder for v8.1M: converting the
A32/T32 Neon decoder to use decodetree. I've done the "post-v8.0
extensions" instructions, and started on the loads-and-stores.
thanks
-- PMM
Hi,
We are having some serious problems after we upgraded from C++14 to C++17
on an Jetson TX2 ARM device. Our system tests started to behave differently
and fail.
It seems that when our application uses a library (also developed by us)
some data gets corrupted when delivered to a class constructor. For
example, the .second of and std::pair<float> appears to be the .first and
the .second is garbage. This is deterministic, but different tests are
failing depending on the combination: library C++17/C++14 <-> application
C++14/C++17.
This is on Ubuntu 18.04 and gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04).
Nothing like this happens on Intel.
So:
ARM, C++14: OK
Intel, C++14: OK
ARM, C++17: FAIL
Intel, C++17: OK
Any ideas what could cause this? I know this is a bit vague, but this a
commercial, closed-source application so I cannot yet give any other
information.
BR,
Jussi Lind
[VIRT-349 # QEMU SVE2 Support ]
Posted the first incremental patch set
for review, as requested by Qualcomm.
[VIRT-327 # Richard's upstream QEMU work ]
Patch review, much of it 5.0 related,
but also v6 of the riscv vector patch set.
Revise the PIE and linkage patch set.
r~
== Progress ==
* GCC upstream validation:
- reported a couple of failures/regressions
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are. Fixed a few
testcases. Managed to use qemu-system-arm to run cortex-m33 code with
CMSE features. (Thanks to Peter Maydell for the help!)
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* FDPIC GDB
* GCC/cortex-M
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Softfreeze this week, so a lot of pull request handling, and
one last small arm pullreq to put together and send out
- Our Coverity Scan setup was broken (the person who usually does
the builds updated his machine to a newer Fedora which broke the tool).
I pulled up an old patchset I had from a year ago which scripts things
so you can do a build-and-upload automatically via Docker so that
we're not dependent on one person for this. This took longer than I
expected as there were a bunch of things that needed fixing both in
the scripting and in bits of the codebase that the tools warned about.
Patch series sent.
- When we did get a Coverity run through, it reported 112 new issues;
spent some time going through and triaging them (lots of false positives
but also lots of real bugs) and submitting patches for some of them.
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
- sketched out the work required and created some 'story' level
cards to go under the epic. Still open questions:
+ should we model Cortex-M55 or a more generic 'max' CPU?
+ what board model do we want to use?
+ does LITE have any guest code using v8.1M features for testing?
Random notes:
* my new desk chair and standing desk arrived this week
(the latter still needs assembling...) so I am gradually
improving the rough edges of my WFH setup.
thanks
-- PMM
== Progress ==
* Out of office 1 day
* More Morello
- Patch set for the 'disassemble' command in review
- Working on the final part of the capability formatting
== Plan ==
* More Morello
Progress:
[VIRT-349 # QEMU SVE2 Support ]
10 of N insn groups implemented.
Annoyingly, there doesn't seem to be a summary of new insns, so confirming that
all of the insns have been implemented.
[VIRT-327 # Richard's upstream QEMU work ]
Patch review. Mostly Phil's arm --disable-tcg set.
Cleanup for some of the new Coverity reports.
Flush tcg patch queue.
[GCC]
Two revisions improving TImode comparisons for aarch64 (PR94174).
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542447.html
[Kernel]
Follow-up on a discussion a few weeks ago re __range_ok. The gcc cmpti patch
set is in support of that, but I also found a much better solution for constant
sized checks.
http://lists.infradead.org/pipermail/linux-arm-kernel/2020-March/719754.html
r~
VirtIO Related Work ([VIRT-366])
================================
- Whole bunch of scoping work on tasks for this cycle
- Briefed the TSC Strategic Meeting on work plan
- Feedback on Friday call seemed positive, hopefully will get the
votes
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- posted [PATCH v1 00/28 for 5.0] testing and gdbstub Message-Id:
<20200316172155.971-1-alex.bennee(a)linaro.org>
- now merged and parent cards closed out including
<https://projects.linaro.org/browse/VIRT-26>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v1 0/5] testing updates (docker and acceptance CI
tweaks) Message-Id: <20200309202318.3481-1-alex.bennee(a)linaro.org>
- spent a fair time fighting with check-acceptance tests weirdness
- fielded questions from potential students for GSoC cache modelling
project
- more time tracking down "check-acceptance" issues
- posted [RFC PATCH for 5.0] configure: disable MTTCG for MIPS
guests Message-Id: <20200320114522.16273-1-alex.bennee(a)linaro.org>
Completed Reviews [2/2]
=======================
[PATCH v10 0/3] Acceptance test: Add "boot_linux" acceptance test
Message-Id: <20200317141654.29355-3-crosa(a)redhat.com>
[PATCH 0/5] QEMU Gating CI
Message-Id: <20200312193616.438922-5-crosa(a)redhat.com>
Absences
========
- Splitting time between work and home-schooling
Current Review Queue
====================
* [PATCH 0/2] thread: add lock guard macros
Message-Id: <20200311123624.277221-1-stefanha(a)redhat.com>
Added: <2020-03-11 Wed>
* [PATCH v8 0/9] qemu-binfmt-conf.sh
Message-Id: <20200307170251.GA7@dd5f6ec33fb0>
Added: <2020-03-08 Sun>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: minor follow-ups
* GCC upstream validation:
- reported a couple of failures/regressions
- PR90378 working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os. Looks like a stack corruption issue
* GCC:
- comparing testsuite results for cortex-m3 and cortex-m33 with
cortex-a9 to check what cortex-M problem there are.
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
* GCC/cortex-M
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Softfreeze this week, so a lot of pull request handling, and
one last small arm pullreq to put together and send out
- Our Coverity Scan setup was broken (the person who usually does
the builds updated his machine to a newer Fedora which broke the tool).
I pulled up an old patchset I had from a year ago which scripts things
so you can do a build-and-upload automatically via Docker so that
we're not dependent on one person for this. This took longer than I
expected as there were a bunch of things that needed fixing both in
the scripting and in bits of the codebase that the tools warned about.
Patch series sent.
- When we did get a Coverity run through, it reported 112 new issues;
spent some time going through and triaging them (lots of false positives
but also lots of real bugs)
thanks
-- PMM
== Progress ==
* Out of office 1 day
* More Morello ('disassemble' command)
== Plan ==
* More Morello
* Will probably be out of office more with toddler
Howdy,
1st post on this list.
I just tried the windows binaries found on the latest-7 release site,
namely of:
gcc-linaro-7.5.0-2019.12-i686-mingw32_arm-linux-gnueabihf
When I go into the bin folder and enter:
.\arm-linux-gnueabihf-gdb.exe --version
It outputs nothing, just returns. The version I used prior, 7.3.1, still
works as supposed.
Notable is that from 7.3.1 to 7.5.0, the gdb.exe size grew from ~96MB to
~128MB.
I re-downloaded the whole tar again and replaced the bin folder, no change.
I can actually *build* a C++ project with those binaries, though, and
the output executable works.
Only GDB seems to be affected so far.
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Reorg sve load/stores w/probe_access_flags.
Posted v6, now including support for sve.
[VIRT-327 # Richard's upstream QEMU work ]
Posted v3 of tbi cleanups.
Updated a forgotten patch vs sve fmla/fcmla.
Oodles of patch review.
r~
VirtIO Related Work ([VIRT-366])
================================
- posted [PATCH] tools/virtiofsd: add support for --socket-group
Message-Id: <20200312104142.21259-1-alex.bennee(a)linaro.org>
- continued discussion on approaches on virtio-dev list Message-Id:
<874kv15o4q.fsf(a)linaro.org>
- email threads with Qualcomm Message-Id:
<CAHFG_=WY8duYm7xNTNo=iGZKqD12gt9ps05pyc1qmbUDcLM0Bw(a)mail.gmail.com>
to drill down on their requirements
- two long HOs with Qualcomm and Google to further discuss work
- I feel like there a few tasks forming which I will try an clean-up
the breakdown on the initiate for next week.
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v1 0/5] testing updates (docker and acceptance CI
tweaks) Message-Id: <20200309202318.3481-1-alex.bennee(a)linaro.org>
- spent a fair time fighting with check-acceptance tests weirdness
- had an initial look at [PATCH 0/5] QEMU Gating CI Message-Id:
<20200312193616.438922-1-crosa(a)redhat.com>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [6/6]
=======================
[PATCH v7 00/18] Add Allwinner H3 SoC and Orange Pi PC Machine
Message-Id: <20200310213203.18730-1-nieklinnenbank(a)gmail.com>
[PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-11-eric.auger(a)redhat.com>
- CLOSING NOTE [2020-03-11 Wed 17:18]
Already merged upstream
Added: <2020-03-03 Tue>
{PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
- CLOSING NOTE [2020-03-12 Thu 09:58]
Not plumbed into the testing infrastructure so a bit of a code dump.
Added: <2020-02-13 Thu>
[PATCH v3 02/10] tests/vm: Add configuration to basevm.py
Message-Id: <20200310182536.11137-3-robert.foley(a)linaro.org>
[PATCH 0/4] tests/vm: minor install tweaks, update netbsd & freebsd
Message-Id: <20200310083218.26355-1-kraxel(a)redhat.com>
[PATCH 0/5] docs/system: Split target-arm.rst
Message-Id: <20200309215818.2021-3-peter.maydell(a)linaro.org>
Absences
========
- None
Current Review Queue
====================
* [PATCH 0/2] thread: add lock guard macros
Message-Id: <20200311123624.277221-1-stefanha(a)redhat.com>
Added: <2020-03-11 Wed>
* [PATCH v8 0/9] qemu-binfmt-conf.sh
Message-Id: <20200307170251.GA7@dd5f6ec33fb0>
Added: <2020-03-08 Sun>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- More documentation cleanup (splitting the Arm boards section
up into one page per board)
- Various patch review
- Put together last large pull request before softfreeze hits next week
- Fixed the Windows installer generation, which I broke in the
process of moving the HTML docs around
- Fixed read buffer overrun in i82596 device model spotted by coverity
- Fixed a user-experience papercut that's been bothering me for years:
for arm you needed to specify '-M virt' to avoid an error even if all
you wanted was the '-cpu help' or '-device help' output.
* VIRT-241 [QEMU ISA Support for A-profile]
- Jira gardening: split out the optional parts of each architectural
tick sub-epic, and added the new 8.6 tasks
thanks
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: patch accepted and committed
* GCC upstream validation:
- reported a couple of failures/regressions
- PR90378 working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
Hi Sir,
I have some questions for tool chain:
1. Can the latest version “linaro-gcc/7.5” support ARMv9 new ISA?
2. If not, when will the new release version can support?
Thanks a lot.
Chun-Chia
VirtIO Related Work ([VIRT-366])
================================
- Followed up with ARM on the roll of Hafnium and secure partitioning
with VirtIO
- Continued working through various requirements for the work
- raised [VIRT-373] to describe some potentially common work on
handling userspace backends
- started discussion on approaches on virtio-dev list Message-Id:
<874kv15o4q.fsf(a)linaro.org>
- posted [RFC PATCH] tools/virtiofsd: add support for --socket-group
Message-Id: <20200304185025.19853-1-alex.bennee(a)linaro.org>
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
[VIRT-373] <https://projects.linaro.org/browse/VIRT-373>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v1 00/10] testing/next updates (tweaks and
re-greening) Message-Id:
<20200302181907.32110-1-alex.bennee(a)linaro.org>
- posted [PULL 0/9] testing updates (tests/vm and acceptance tweaks)
Message-Id: <20200304100154.14822-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[PATCH v3 00/33] Convert qemu-doc to rST
Message-Id: <20200228153619.9906-1-peter.maydell(a)linaro.org>
[PATCH v5 00/50] Initial support for multi-process qemu
Message-Id: <cover.1582576372.git.jag.raman(a)oracle.com>
- CLOSING NOTE [2020-03-02 Mon 18:20]
Initial pass, mostly checking wasn't CI broken, which it was.
Added: <2020-02-28 Fri>
[PATCH v6 00/18] Add Allwinner H3 SoC and Orange Pi PC Machine
Message-Id: <20200301215029.15196-1-nieklinnenbank(a)gmail.com>
Absences
========
- None
Current Review Queue
====================
* [PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-11-eric.auger(a)redhat.com>
Added: <2020-03-03 Tue>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- found and fixed some bugs in our "hflags caching" for M-profile
which caused spurious assertions in some corner cases
- got the rST conversion patchset through review and into master
- sent some followup cleanup patches that remove some texinfo
related bits of code we no longer need
- patch review:
+ rth's final respin of the "honour more HCR_EL2 traps" series
+ patchset fixing some memory leaks of timer objects
+ patchset for cubieboard model to error out rather than ignoring
some bogus user command line options
* VIRT-241 [QEMU ISA Support for A-profile]
+ Wrote an implementation of v8.2-TTS2UXN; investigating how best
to test it
thanks
-- PMM
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Lots of work, including an arch update. The system-mode patch set is much
changed, but still not quite ready.
[VIRT-349 # QEMU SVE2 Supprt ]
[VIRT-327 # Richard's upstream QEMU work ]
TBI fixes, 2 rounds.
HCR fixes, 2 rounds.
TCG patch queue flushed.
Some patch review.
r~
Good afternoon,
I would like to announce the breakthrough in extending gdb with non
intrusive instructions and functions tracing on ARM processors using
Coresight ETM traces, as described in previous mails.
the source code is made public in the git repository
https://github.com/gzied/binutils-gdb/ in the branch gdb_arm_coresight.
this implementation was compiled and tested on an STM32MP1 (ARMv7
Architecture) board running "Linux arm 5.3.10-armv7-lpae-x15" distribution
where the device tree was modified to declare CoreSight components.
to build the software
>checkout the software from the branch gdb_arm_coresight
> cd ..
>mkdir build
>cd build
> ../binutils-gdb/configure --with-arm-cs
>make
after a successful build gdb will be available in the folder build/gdb
to run the software
build the software you would like to debug with debugging info (-g flag)
>gcc -g software.c -o software
start debugging your software
>gdb software
set a breakpoint at main
(gdb) b main
(gdb) run
set a breakpoint in a location after the code you would like to trace
(gdb) b my_function
set your etm sink, sinks can be found by listing the folder
/sys/bus/event_source/devices/cs_etm/sinks/. use a sink that is capable of
storing the traces on chip (etf, etb ...)
(gdb) set record btrace etm sink tmc_etf0
start recording etm traces
(gdb) record btrace etm
continue the execution of the program
(gdb) c
wait until the breakpoint is hit,
analyse and display the traces
- on assembly level
(gdb) record instruction-history
- on c level
(gdb) record function-call-history /ilc
you can increase the number of instructions displayed by using
(gdb) set record instruction-history-size size
(gdb) set record function-call-history-size size
the work is still in an early stage and needs to be improved, extended and
stabilized. your feedback and contributions are welcome
Kind Regards
Zied Guermazi
VirtIO Related Work ([VIRT-366])
================================
- had a couple of HOs and internal threads to flesh out understanding
for VirtIO work
- queried VIRTIO adoption in other hypervisors Message-Id:
<87mu93vwy2.fsf(a)linaro.org> to help understanding
- need a meeting with QC/NXP to discuss their requirements and why
they need certain devices in VirtIO
- a lot of the Android focus seems to be on isolating various secure
workloads
- avoiding needing secure but un-trusted code at elevated privileges
with access to main OS
- suspect the breakdown in the card needs re-arranging
[VIRT-366] <https://projects.linaro.org/browse/VIRT-366>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2 00/12] testing/next (with build fixes!) Message-Id:
<20200130113223.31046-10-alex.bennee(a)linaro.org>
- posted [PULL 00/19] testing and plugin updates Message-Id:
<20200226073929.28237-1-alex.bennee(a)linaro.org>
- did some debugging/diagnosis for recent slowdown of ARM emulation in
master Message-Id:
<CAPan3Wq-MVwcJQELP8n+g33CR7tsiGXQ698gA177nd2my9hWCw(a)mail.gmail.com>
- posted [PATCH v1 0/4] Fix codegen translation cache size
Message-Id: <20200226181020.19592-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-1-eric.auger(a)redhat.com>
- CLOSING NOTE [2020-02-26 Wed 15:37]
It's in an in-flight PR now, will play with it once it lands.
Added: <2020-02-14 Fri>
[PATCH RISU] aarch64.risu: Add patterns for v8.3-RCPC and v8.4-RCPC insns
Message-Id: <20200225143923.22297-1-peter.maydell(a)linaro.org>
[PATCH v3 0/3] Fix number of priority bits for arm boards
Message-Id: <1582537164-764-1-git-send-email-sai.pavan.boddu(a)xilinx.com>
- CLOSING NOTE [2020-02-28 Fri 17:22]
Have been pulled into target-arm next but didn't fix the
kvm-unit-test failures with priority masking as I had hopped they
would.
Added: <2020-02-25 Tue>
Absences
========
- None
Current Review Queue
====================
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
* [PATCH v2 0/7] configure: Improve PIE and other linkage
Message-Id: <20191218223441.23852-1-richard.henderson(a)linaro.org>
Added: <2020-01-06 Mon>
--
Alex Bennée
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Got confused by QEMU aborting in the PMU code on a GICv3-only host,
which turns out to be because our error handling for "no GICv2
support" was broken. Sent a patch.
- Another push towards getting texi-to-rST conversion done:
+ Converted a few more simple texi doc files to rST
+ Took up a patchset Paolo did for more automated conversion, and
sorted out the parts it didn't deal with, to get it to a point
where it could delete almost all of the texinfo sources. Sent
a big patchset to the list for review.
- patch review:
+ Gumstix cleanup patchset
+ rth's series to honour more HCR_EL2 traps
+ add a few missing devices to integratorcp
+ get the number of implemented priority bits in GICv2 right
* VIRT-241 [QEMU ISA Support for A-profile]
- Implemented the v8.3-RCPC, v8.4-RCPC and v8.3-CCIDX extensions,
and sent patches to the list
thanks
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted updated v5
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m. Fix
committed to trunk and backported to gcc-9
* GCC upstream validation:
- reported a couple of failures/regressions
- working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
Four day week.
[VIRT-344 # ARMv8.5-MemTag, Memory Tagging Extension ]
Lots of work here.
Noticed that our TBI handling is wrong for system mode, such that the FAR_ELx
register gets the wrong contents. Noticed that SVE isn't handling TBI at all,
much less being prepared for MTE. Noticed that even AdvSIMD would not quite
produce the correct results for LD*/ST* (multiple structures).
Rearranging the actual MTE check from the ground up. Found an odd case with
DC_ZVA that threw a wrench into that planning.
[VIRT-327 # Richard's upstream QEMU work ]
Honor more HCR_EL2 trap bits.
HPPA patch queue flushed.
Patch review for ppc "hardfloat" patch.
Patch review for memory_region_allocate_system_memory.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- Sent out a patchset creating a 'tools' manual and moving some
docs into it that were previously in the 'interop' manual
- more code review this week than last week
- pushed out another arm pullreq
* VIRT-241 [QEMU ISA Support for A-profile]
- several patches implementing features landed in master,
so I was able to close out some of the subtasks here
thanks
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: handling feedback received
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m. All new
failures reported with cortex-m0 + -mpure-code are to be expected
(mainly testcases forcing options incompatible with -mpure-code)
* GCC upstream validation:
- reported a couple of failures/regressions
- looked at a problem with LTO profiled bootstrap failing on aarch32
with gcc-8. Could not reproduce with current trunk
- working on reproducing a non-functional code problem with spec2006
on arm with LTO and -Os
* misc:
- infra fixes / troubleshooting / reviews
- looked at a problem reported about addr2line and kernel symbols.
Needs more analysis
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* spec2006 / LTO / Os / aarch32
* FDPIC GDB
== Progress ==
* More Morello (updating for new capability encoding)
* Tiny amount of GlobalISel arm32 maintenance (not committed yet)
== Plan ==
* More Morello
Same comment applies with regards to mailing lists.
On Mon, 17 Feb 2020 at 10:16, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> Hi Mike, hi Matthieu,
>
> I was too rapid to press the send button, sorry for the inconvienience.
> and yes, it works. I published the source code in github (https://github.com/gzied/binutils-gdb/tree/gdb_arm_coresight) ,as well as a mail in linaro mailing list (https://lists.linaro.org/pipermail/coresight/2020-February/003676.html).
Unfortunately you didn't publish your work in "PATCH" format and as
such it can't be reviewed.
> Eventhough there is still an effort needed to stabilize it for armv7, and test it for armv8, I consider this as a breakthough that we can build on the top of it.
> I will be visiting Embedded world exhibition between 25th and 27th of February in Nuremberg, Germany. are you planning to be there too. I am looking forwards to meet you there if possible to discuss possibilities of further development and integration in the main stream.
I won't be in Nuremberg next week and I'm pretty sure Mike won't be
there either. Other people on the lists might be around and
interested in meeting with you. Mike and I will be attending Linaro
Connect in Budapest between the 23rd and 27th of March. The Linaro
toolchain group will also be there so it might be the perfect
opportunity to sit down for an hour or so and have a chat.
A good day to you,
Mathieu
>
> Kind Regards
> Zied Guermazi
>
>
>
>
>
> On Monday, February 17, 2020, 06:08:26 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> Hi Mike, hi Matthieu
> it works!
>
>
>
> On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> hi Mike, hi Mathieu
> last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level.
> so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7).
> I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here?
>
> during the implementation few technical question raised:
> - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress)
> - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs.
>
> for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call?
>
> I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round.
>
> Thanks for your support
> Zied Guermazi
>
>
i
Hi Zied,
As requested before, always add the CS mailing list when interacting
with us. There is a fair amount of people on there that would surely
be interested in this work. I also CC'd the linaro-toolchain group
since some of the content below is related to what they do.
On Mon, 17 Feb 2020 at 10:08, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
> Hi Mike, hi Matthieu
> it works!
>
>
>
> On Monday, December 16, 2019, 11:20:20 PM GMT+1, zied guermazi <guermazi_zied(a)yahoo.com> wrote:
>
>
> hi Mike, hi Mathieu
> last few weeks I was able to spend some time on implementing this feature, and I want to share the status with you and get your recommendation on organizational and technical level.
> so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7).
> I would like to push this on git, first for review and second for integration and creating traction . Do you think it is ok to push it in this status (feature partially achieved) ? is linaro gdb git the correct one? who is the maintainer of this part of gdb? I do not have an ARMv8 platform to test. who can support here?
I will address your questions one by one:
Q: Do you think it is ok to push it in this status (feature partially
achieved) ?
A: That depends on how advanced things are. If it is stable (i.e it
does something) and can be used as a starting point for other people
to work on, then there is probably value in publishing your work.
Q: is linaro gdb git the correct one?
A: I see from your other email that you've already published your work.
Q: who is the maintainer of this part of gdb?
A: I'm sure the GDB project has documentation and a well defined
process that would identify who you should submit your code to.
Q: I do not have an ARMv8 platform to test. who can support here?
A: No doubt you'd get a lot more interest if you were working on V8.
I suggest purchasing a dragonboard 410c - they are super cheap, well
supported and one of our CS reference platforms. I think we talked
about that before...
>
> during the implementation few technical question raised:
> - etm tracing collection requires selecting a trace sink. and I have two alternatives: either extending the "record btrace etm" command (used to start tracing) with a sink as an argument or extending the command "set record btrace" (general configuration of tracing) with etm sink sub-command? (I have hard-coded it currently to be able to progress)
I would assume this "set record btrace" command has an effect on the
current session only. If so I would go for the latter option.
> - currently I am hardcoding the path "/sys/bus/event_source/devices/cs_etm/" as the default etm source, is this guaranteed to be unique? can we have a system with many etm sources enumerated in the sysfs.
>
I am very confused by this question. Yes, the path
"/sys/bus/event_source/devices/cs_etm/" is guaranteed to be unique but
it is by no means a "default source". Is is simply a directory used
by the perf tools to have more details on the CS specifics for the
running platform. Nowadays it is fair to assume there is one ETM perf
CPU, all enumerated under sysfs. Also keep in mind that processes are
being moved around by the scheduler and as such, a specific source
can't be hard coded.
> for parsing the traces I will need some configuration parameters like the content of registers ETMCR, ETMIDR, ETMCCER, ETMTRACEIDR. if my understanding of the implementation of perf is correct, it is collecting them from the sysfs files located in /sys/bus/event_source/devices/cs_etm/cpu0/mgmt/. which are global for the system. my question is what will happen if two process are requesting tracing at the same time? how to differentiate between traces going to one session from the second one? is it possible to get the parameters of a given session by some kind of ioctl request to the file descriptor we get out of sys_perf_open call?
Configuration of the tracers does indeed need to be considered. At
this time we assume all the tracers in an implementation are similar,
hence using ".../cpu0/mgmt". The information gathered from there is
related to the static configuration of the tracers. Per session
dynamic configuration is collected from the perf tools command line
and communicated to the perf infrastructure for later interpretation
by the decoding code when instantiating a decoder from the openCSD
library. Since the current framework handles only N:1 source/sink
configuration, there can only be one trace session using a sink.
There is currently no way to extract trace session configuration other
than the user space perf tools mechanic.
>
> I will publish those queries in the linaro coresight and gdb forums, I wanted first to align with you especially on the organizational issues, before going to a bigger round.
>
> Thanks for your support
> Zied Guermazi
>
>
== Progress ==
* More Morello (updating for new capability encoding)
* Went to the embassy to get my passport
* Read a couple ARM policy refreshers...
== Plan ==
* More Morello
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v4
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
posted updated patch for latent bug on trunk
* GCC upstream validation:
- reported a couple of failures/regressions
- fixed FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* FDPIC GDB
VirtIO Related Work
===================
This is essentially a mind-map of bullet points as we work out what
concrete work items should be implemented by the TCWG Virt hackers
(most likely just me ;-)
Xen for Automotive ([LBI-24])
- Things that need doing
- support for virtio in core (i.e. not just emulated devices)
- support for virtio-iommu and sharing memory between guests
(ivshmemv2?)
- support virtio over ivshmemv2 (would native virtio be supported?)
- support for vhost over shared memory (zero copy device emulation)
- support isolating userspace emulation from hvm (vhost-user)
- Why?
- userspace emulation has performance benefits (exit-less, polling)
- growing number of virtio devices for that guests support
[LBI-24] <https://projects.linaro.org/browse/LBI-24>
Virtualizing Android ([LBI-38])
- Builds on Google's work on Cuttlefish
- New Android Device model using VirtIO (including VirtGPU) \o/!
- Used to run on QEMU, now targeting CrosVM
- Potential interest in using as a HAL layer
- Potential work items
- Better support for ARM in CrosVM
- Is QEMU of interest to members? (emulation & tooling - unlike
CrosVM)
- Is a virtualised Android HAL possible
- Where does Hafnium fit it?
[LBI-38] <https://projects.linaro.org/browse/LBI-38>
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- re-based [a v7 branch]
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
[a v7 branch]
<https://github.com/stsquad/qemu/tree/gdbstub/sve-registers-v7>
Upstream Work ([VIRT-109])
==========================
- posted [PATCH v2 00/12] testing/next (with build fixes!) Message-Id:
<20200130113223.31046-10-alex.bennee(a)linaro.org>
- posted [PATCH v2 00/19] testing and plugin updates Message-Id:
<20200213225109.13120-1-alex.bennee(a)linaro.org>
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[RFC PATCH 1/2] GitLab CI: avoid calling before_scripts on unintended jobs
Message-Id: <5d0def0e-0943-3345-784d-80f8ccc318b9(a)redhat.com>
[PATCH v1 00/14] tests/vm: Add support for aarch64 VMs
Message-Id: <20200205212920.467-1-robert.foley(a)linaro.org>
- CLOSING NOTE [2020-02-07 Fri 19:56]
Some problems with hangs, not sure about using threads/file
approach.
Added: <2020-02-06 Thu>
[PATCH 0/2] target/arm: Pass arguments by value for sve FMLA/FCMLA
Message-Id: <20200212025145.24300-1-richard.henderson(a)linaro.org>
Absences
========
- 17t-24th Feb Half Term
- 23rd-27th March BUD20
Current Review Queue
====================
* [PATCH v16 00/10] VIRTIO-IOMMU device
Message-Id: <20200214132745.23392-1-eric.auger(a)redhat.com>
Added: <2020-02-14 Fri>
* [RFC][PATCH 0/3] IVSHMEM version 2 device for QEMU
Message-Id: <cover.1573477032.git.jan.kiszka(a)siemens.com>
Added: <2020-02-14 Fri>
* {PATCH v2 0/2} tests/tcg/multiarch: Add tests for implemented real
Message-Id: <1581603905-21565-1-git-send-email-Filip.Bozuta(a)rt-rk.com>
Added: <2020-02-13 Thu>
* [RFC 0/9] Add an interVM memory sharing device
Message-Id: <1580815851-28887-1-git-send-email-i.kotrasinsk(a)partner.samsung.com>
Added: <2020-02-05 Wed>
--
Alex Bennée
Progress:
* VIRT-241 [QEMU ISA Support for A-profile]
- Looking into implementing some of the easier, smaller architecture features
- Implemented ARMv8.1-VMID16 (16-bit VMID support), which is trivial
for QEMU because it doesn't care much about VMIDs
- Working on ARMv8.1-PMU and ARMv8.4-PMU: it turns out that we already have
most of these extensions, so we just need to finish off some smaller pieces
and fix one or two bugs. Sent out a patchset implementing these.
- Found a bunch of ID-register related bugs in the process, which I have
fixes for
- Implemented the "mandatory from v8.2" ACTLR2 and HACTLR2 registers
* VIRT-65 [QEMU upstream maintainership]
- code review:
- series from Laurent fixing a long-standing issue with handling of
realtime signals in our linux-user code
- imx6 model patches to fix a watchdog device bug and add the
watchdog to our imx6 boards
- final few unreviewed patches in rth's "PAN, ATS1E1, UAO" series
- respin of the json QAPI Sphinx conversion patchset; hopefully the
first half of this is now uncontroversial cleanups that can go in
while the second half gets code reviewed
thanks
-- PMM
o LLVM:
* 10.0.0 RC:
- reported issues upstream
- upload AArch64 binaries
* IR Outliner:
- looking at the branch status
o Misc
* Resurrected an old GNU toolchain prototype w/r to Linux kernel
size reduction.
* Various meetings and discussions.
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: posted v3, no feedback yet.
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m:
reproduced latent bug on trunk, fix accepted, but I'm still worried by
it not setting all insn attributes correctly.
* GCC upstream validation:
- reported a couple of failures/regressions
- FDPIC build broken on trunk
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
* Fix FDPIC build
[ Linux on ARM mini-conference ]
2 days. Some interesting stuff in the future hardware directions talks.
Helped out a bit with ABI history in the toolchain breakout session. Some good
hallway discussion, especially re record-replay on aarch64.
I should make time this weekend to produce a more complete trip report.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
Posted v7 -- merged!
[VIRT-262 # ARMv8.1-PAN ]
[VIRT-273 # ARMv8.2-ATS1E1 ]
[VIRT-276 # ARMv8.2-UAO ]
Posted v3.
[VIRT-327 # Richard's upstream QEMU work ]
Random patch review.
Updated some aa32 vfp cleanup patches; still need to
re-test and post.
r~
Progress:
* VIRT-65 [QEMU upstream maintainership]
- sent pullreq with some of the pending rST doc conversion work
- finished the work on converting the json QAPI doc comments from
texinfo to rst, and sent out a patchset for this
- code review:
- Cornelia's patches rstifying some s390 docs
- rth's 'Reduce aa64_va_parameter overhead' patch
- a patchset fixing some minor memory leaks in timer devices
- rth's PAN/ATS1E1/UAO patchset
- sent out an arm pullreq
I seem to be currently keeping on top of the code-review queue
with about an afternoon a week spent on review, which is pleasing.
thanks
-- PMM
Progress:
* VIRT-65 [QEMU upstream maintainership]
- more work on rST doc conversion. I've started in on converting the
documentation that we auto-generate from doc comments in json files
(this covers QEMU's QMP protocol and a similar protocol for the
guest-agent).
I now have something that is basically the right shape and correctly
handles 'Command' and 'Object' (with 'Enum' and Alternate' and some
other corner cases still to do). Might be able to send a patchset out
next week with luck. This is I think the last major obstacle to the
rST conversion -- once it's done the rest is just simple-but-tedious
conversion of the remaining document files.
- code review:
+ aspeed 'misc fixes and extensions' patchset
+ "Stop wrongly programming GICR_PENDBASER.PTZ bit" bugfix patch
+ KVM 'adjust virtual time when VM starts/stops' patchset
+ last few unreviewed patches in RTH's VHE patchset respin
-- PMM
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: fixed bugs found when
running the testsuite with the new option activated. Adding warnings
to help understand potential placement changes.
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m: the
patch applies cleanly in the branch, but there are unexpected failures
compared to trunk. Debugging.
* GCC upstream validation:
- reported a couple of failures/regressions
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
== Progress ==
* Updating lldb for the latest Morello architecture changes
* Started running the tests for llvm 10.0.0-rc1
== Plan ==
* Check up on the release
* More Morello
[LLD]
Fixed interworking problem causing Thumb2 kernel not to
Some diagnosis of LLD problem when .ctor and .init_array initialisers are used.
[LLVM-MC]
Upstream reviews for some methods to avoid llvm-mc making symbols
inter-positionable that the code generator has assumed are not.
[Morello]
reviews.
[Other]
Clean up my Jira tickets so that they can be passed on or closed.
This is my last week as a Linaro assignee, will be going back to the
Arm as of next week. I've really enjoyed my time here, thank you for
having me.
Buildbots, busy week that took up most of spare time
- deploying timezone fix to containers
- a couple of weekend patches that broke Arm and AArch64 bisected and
followed up.
- difficult to track down stage-2 failure that was difficult to work
out whether there was a bug in clang, or a code-gen failure in the
backend, also made it harder to bisect. Turned out that it had caused
more easy to bisect failures in other projects and by the time I'd
found the patch it had been fixed.
[ClangBuiltLinux]
LLD's simplified interworking looks to be insufficient for the linux
kernel thumb-2 build. Got agreement with upstream on how to proceed.
Have a patch ready to send upstream.
A small amount of upstream review and bisecting some Linaro CI build
failure for the -fpatchable-functions feature in Clang-10. Looks to
have been resolved.
[VIRT-327 # Richard's upstream QEMU work ]
* tcg patch queue flush, including some VHE prereqs.
* target/hppa patch queue flushing.
* combined the two in-flight avr patch sets, hoping
to move that project to completion.
* patch review.
* target/s390x local variable "leak" fix,
to satisfy a static analyzer.
[VIRT-263 # ARMv8.1-VHE Virtual Host Extensions ]
* started rebasing, and addressing the collected
comments from v4 in December.
r~
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: debugging
* GCC:
* GCC-9: continued work for validation of -mpure-code on v6m: local
newlib/crt0 patches, patched simulator. Running various validation
configurations
* GCC upstream validation:
- reported a couple of failures/regressions
* misc:
- infra fixes / troubleshooting / reviews
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
Progress:
* VIRT-65 [QEMU upstream maintainership]
- code review:
+ RTH's bug fix for the PAuth ComputePAC operation
+ patchset adding DMA support for Exynos4210 UARTs
- small patchset documenting the right way to conditionally run
expensive computations that are only needed for trace event output,
and updating a handful of places that used an older (worse) method
- more QEMU documentation conversion to rST; in particular wrote a
Sphinx 'hxtool' extension to handle pulling out fragments of documentation
from QEMU's '.hx' files which define and document command line options
thanks
-- PMM
hiI am progressing in the implementation of the proposal "GDB process record and replay with ARM Coresight" https://lists.linaro.org/pipermail/coresight/2019-July/003021.html
so far I was able to use perf events to configure the drivers for etm and collect the traces. the code was tested successfully on an STM32MP157A discovery kit (arm v7). and I can collect the traces from the perf mmapped aux area.
For parsing them I needed to gather information about the cpu and etm registers. those are available in the events of type PERF_RECORD_AUXTRACE_INFO in the priv section. priv is a kind of "opaque" data structure where the layout is depending on the perf pmu drivers. the implementation of perf tool gives a good example to follow. I needed also to make a wrapper around opencsd library and again perf was offering a good example to follow.
those are good reasons to think about factoring out the functionality of parsing etm traces on linux system in a dedicated library that can be reused by other software, a kind of libcoresightperf.is there any plan or ongoing activities for such a library?
Kind RegardsZied Guermazi
== Progress ==
* More EuroLLVM submissions reviews
* More investigations into Morello bare metal debugging
* Started looking into updating lldb for the latest Morello architecture
changes
* Asked Adhemerval to look into PR44157
== Plan ==
* More Morello
* Keep an eye out for 10.0.0 - rc1
[VIRT-327 # Richard's upstream QEMU work ]
* Implement x86_64-linux-user vsyscall page,
which should keep Peter's pre-merge testing working.
* Another tcg queue pull without the bits that depend
on the vsyscall implementation above.
* Posted v2 of some fixes to -accel option processing.
* Posted v2 of some fixes to target/arm syn data syndrome bits.
* Wrote some test cases for a target/arm pauth sbox fix.
* Investigated a fix for memory layout of -static-pie binaries.
* Random patch review.
r~
QEMU Tooling ([VIRT-252])
=========================
Extend gdbstub for SVE ([VIRT-281])
- posted [PATCH v5 00/22] gdbstub refactor and SVE support (+check-tcg
tweaks) Message-Id: <20200114150953.27659-3-alex.bennee(a)linaro.org>
[VIRT-281] <https://projects.linaro.org/browse/VIRT-281>
Upstream Work ([VIRT-109])
==========================
- played with [for-5.0 PATCH 00/11] Support for reverse debugging with
GDB Message-Id:
<157709434917.12933.4351155074716553976.stgit@pasha-Precision-3630-Tower>
- still broken but could be build stability
- while reviewing vsyscall patches ran into qemu-x86_64, buster
/sbin/ldconfig and setup_arg_pages (a mind dump) Message-Id:
<874kwukmxr.fsf(a)linaro.org>
- posted [qemu-web PATCH] documentation: update links to readthedocs
Message-Id: <20200113103550.1133-1-alex.bennee(a)linaro.org>
- we successfully recovered the qemu project name for rtd
[VIRT-109] <https://projects.linaro.org/browse/VIRT-109>
Completed Reviews [3/3]
=======================
[for-5.0 PATCH 00/11] Support for reverse debugging with GDB
Message-Id: <157709434917.12933.4351155074716553976.stgit@pasha-Precision-3630-Tower>
- CLOSING NOTE [2020-01-13 Mon 18:00]
Introduces some regressions into check-block that need to be fixed
first.
Added: <2020-01-06 Mon>
[PATCH 0/4] migration: Replace gemu_log with qemu_log
Message-Id: <20200114030138.260347-1-jkz(a)google.com>
[PATCH 0/3] linux-user: Implement x86_64 vsyscalls
Message-Id: <20200114210921.11216-4-richard.henderson(a)linaro.org>
Current Review Queue
====================
* [PATCH v2 0/7] configure: Improve PIE and other linkage
Message-Id: <20191218223441.23852-1-richard.henderson(a)linaro.org>
Added: <2020-01-06 Mon>
* {RFC PATCH v3 000/132} Proof of concept for Meson integration
Message-Id: <1576155176-2464-1-git-send-email-pbonzini(a)redhat.com>
Added: <2019-12-12 Thu>
* {PATCH 0/2} tests/acceptance: Add boot vmlinux test
Message-Id: <20191206140012.15517-1-wainersm(a)redhat.com>
Added: <2019-12-06 Fri>
* {RFC PATCH 00/10} hw/avr: Introduce the Arduino board
Message-Id: <20191128015030.27543-1-f4bug(a)amsat.org>
Added: <2019-11-28 Thu>
--
Alex Bennée
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: found problems in the
testsuite when the flag is activated by default
* GCC:
- trying to find a way to add run more validation of -mpure-code on
v6m, to support a request to backport to gcc-9: need to patch newlib's
crt0.S which has some offending sequences
* GCC upstream validation:
- updated scripts to cope with the new git repo and release branches names
* misc:
- infra fixes / troubleshooting / reviews
- fixed problems with automatic bisection of gcc regressions
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
* GCC-9: continue work for validation of -mpure-code on v6m
Morello
- Upstream LLD INPUT_SECTION_FLAGS that I implemented downstream.
Quite a few review comments to work through but I think I'm close to
getting something accepted. This will hopefully come in useful for LLD
with embedded systems.
- Wrote down some definitions for the new relocations.
LLD
- landed fix for clang-built-linux-812 linux allyesconfig problem.
- Quite a few upstream LLD and MC reviews
Other
Some research for the clang built linux conference.
== Progress ==
* Out of office for 2 days
* Reviewed EuroLLVM submissions
* A bit more investigation into Morello bare metal debugging
== Plan ==
* PR44157
* Morello bare metal debugging
Hello Linaro team,
I want to use your cross compiler version 6.3.1, but I miss the library
asound and its header (alsa/asoundlib.h)
What do I need to do to fix this ?
Best regards,
Markus Bollinger
Hi Ana,
I don't know anything about the POC myself, but I'm forwarding this so our
QEMU folks can answer.
Cheers,
Diana
---------- Forwarded message ---------
From: Ana Pazos <apazos(a)quicinc.com>
Date: Fri, 10 Jan 2020 at 19:08
Subject: about QEMU support for SVE2 POC
To: diana.picus(a)linaro.org <diana.picus(a)linaro.org>
Cc: Ana Pazos <apazos(a)quicinc.com>
Hello Diana,
We at Qualcomm are trying to find out the POC for QEMU support for SVE2.
We have been using QEMU with SVE support, and need to find out when SVE2
support will be added to QEMU.
I assume Linaro is involved in this task. Do you know the POC?
Thanks for the help!
Ana.
== Progress ==
* BFD Linker:
- GNU-629: non-contiguous memory support: sent updated versions with
testcases and doc.
* GCC:
- trying to find a way to add run more validation of -mpure-code on
v6m, to support a request to backport to gcc-9
- proposal to implement LLVM's -arm-assume-misaligned-load-store
rejected by the community
* GCC upstream validation:
- reported/checked a few issues
* misc:
- infra fixes / troubleshooting / reviews
- investigating problems with automatic bisection of gcc regressions
- fixed a long-standing bug in proot
== Next ==
* Binutils: GNU-629: support non-contiguous memory regions in linker
[VIRT-327 # Richard's upstream QEMU work ]
* TCG patch queue flush, including phase 1 increase for
number of mmu_idx, on which VHE is dependent.
* Random patch review.
* Capstone update.
* cputlb cleanup in prep for modeling ASIDs.
r~
Morello:
- Implemented INPUT_SECTION_FLAGS in LLD for the Morello toolchain,
now in review. Took most of spare engineering time this week. Will
attempt to upstream once committed in Morello
- Fixed pr44451 upstream, it was already fixed on Morello toolchain.
LLD:
- Made an attempt to fix the LLD linux kernel allyesconfig +
cortex-a53 erratum problem. Was not successful as kernel linker script
is just about as awkward as possible for this problem. I have a good
idea of what to try next. Will aim to fix early next week.
- Quite a few upstream reviews, some pending from last year.
Progress:
* VIRT-65 [QEMU upstream maintainership]
- caught up on the backlog of email that accumulated over the Christmas break
- investigated an intermittent failure of a test case on our BSD hosts
which had reached a failure rate that was seriously impeding the
flow of pull requests. Tracked it down to glib's g_source_ref/unref
not being thread-safe unless the GSource is attached to a GMainContext;
QEMU gets this right for its own use but a set of mock functions used
for a few testcases were not doing so, resulting in occasional races
where the GSource would get destroyed while it was still in use.
- code review:
+ Beata's "inject DABT for load/store insns KVM couldn't emulate" patch
+ a minor cubieboard cleanup patchset
+ i.MX RNGC device emulation patch
- annual review season, some time spent on that
thanks
-- PMM
== Progress ==
* Out of office until Tuesday
* LLVM 9.0.1
- Uploaded final binaries
- Still looking into PR44157 (CFI tests failing on armv7)
* Morello LLDB
- Trying to get bare metal debugging to work
* More ARM Code of Conduct courses etc
== Plan ==
* More Morello and PR44157
* Patch set cleaning up PIE/non-PIE linking
- Add new support for static pie.
* Another revision removing MMU_MODE_SUFFIX.
* Random patch review.
* Planning for Linux on ARM summit in Cambridge in February.
r~
To whom,
I’m seeing a failure on this bot:
--
Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-armv7-quick/stage1/bin/llvm-objdump: error: '/home/buildslave/buildslave/clang-cmake-armv7-quick/llvm/llvm/test/tools/llvm-objdump/Inputs/macho-stabs-x86_64': can't find target: : error: unable to get target for 'x86_64---macho', see --version and --triple.
This is just a binary file verifier. Is it the case this bot doesn’t have a mach-o disassembler? And if so, is there a way to disable this test on this bot?
Thanks!
MDT