Hello Linaro Toolchain Working Group,
Please connect your new bots to the staging first and make them reliably
green there:
linaro-aarch64-flang-debug
linaro-aarch64-flang-latest-clang
linaro-aarch64-flang-latest-gcc
clang-cmake-aarch64-full is red for a month.
https://lab.llvm.org/buildbot/#/builders/7?numbuilds=700
Could you move linaro-aarch64-full to the staging and make it green again,
please?
Please let me know if I could help or you have questions.
Thanks
Galina
Hi Joel,
Indeed, LLD is not configured to be used by default in LLVM-12.0.0-rc1. You need to add -fuse-ld=lld option for it to work. We’ll fix this in the final LLVM-12 release for WoA, which is expected in around 2 weeks.
Thanks for catching this!
c:\Users\tcwg\source\maxim>..\llvm-12.0.0-rc1\bin\clang-cl.exe hello.c
clang-cl: error: unable to execute command: Couldn't execute program 'C:\BuildTools\VC\Tools\MSVC\14.28.29333\bin\Hostx64\arm64\link.exe': Unknown error (0xD8)
clang-cl: error: linker command failed with exit code 1 (use -v to see invocation)
c:\Users\tcwg\source\maxim>..\llvm-12.0.0-rc1\bin\clang-cl.exe -fuse-ld=lld hello.c
c:\Users\tcwg\source\maxim>hello.exe
Hello
c:\Users\tcwg\source\maxim>..\llvm-12.0.0-rc1\bin\clang.exe -fuse-ld=lld hello.c
c:\Users\tcwg\source\maxim>hello.exe
Hello
--
Maxim Kuvyrkov
https://www.linaro.org
> On 4 Mar 2021, at 19:43, Joel Cox <Joel.Cox(a)arm.com> wrote:
>
> Hi
>
> I was trying "clang hello.c" from command line, but "clang-cl hello.c" gives me the same error. I am unsure if this is what you mean but neither work.
>
> Thanks,
> Joel
>
> -----Original Message-----
> From: Maxim Kuvyrkov <maxim.kuvyrkov(a)linaro.org>
> Sent: 04 March 2021 16:40
> To: Joel Cox <Joel.Cox(a)arm.com>
> Cc: linaro-toolchain(a)lists.linaro.org
> Subject: Re: Clang targetting x64 linker
>
> Hi Joel,
>
> Are you using clang-cl.exe as compiler/linker driver? It’s easiest to use clang-cl.exe as it aims to be a direct replacement for MSVC’s cl.exe, but will use LLVM tools. In particular, when clang-cl.exe uses LLVM Linker (LLD) by default.
>
> If you are using linux-style clang.exe as the driver, then you need to specify -fuse-ld=lld to use LLD.
>
> Does this help?
>
> Regards,
>
> --
> Maxim Kuvyrkov
> https://www.linaro.org
>
>> On 4 Mar 2021, at 19:11, Joel Cox <Joel.Cox(a)arm.com> wrote:
>>
>> Hi
>>
>> I've been trying to run clang on a Windows on Arm machine, but it keeps trying to using the link.exe located in "Visual studio/..../Host64/arm64", which is (seemingly) an x64 tool and as such doesn't run, and crashes the process.
>> Is there a way to set clang to look at VS's x86 link.exe? Or if there is an arm64 version that clang should be using instead?
>>
>> Thanks,
>> Joel
>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>> _______________________________________________
>> linaro-toolchain mailing list
>> linaro-toolchain(a)lists.linaro.org
>> https://lists.linaro.org/mailman/listinfo/linaro-toolchain
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Progress:
* UM-2 [QEMU upstream maintainership]
- Mostly caught up on code review now: have done all the patches that
are targeting 6.0
- Sent out some pullreqs with for-6.0 material
- Wrote a patch to make us emulate the right number of counters for
the PMU according to what each CPU should have, rather than always 4
- Had a go at fixing the M-profile vector table load on reset to
handle aliased memory regions
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
- mps3-an524 and -an547 patchseries now in master: this epic is done!
thanks
-- PMM
Folks,
I am pleased to announce the move of libc++ to pre-commit CI. Over the past
few months, we have set up Buildkite jobs on top of the Phabricator
integration built by Mikhail and Christian, and we now run almost all of
the libc++ build bots whenever a Phabricator review is created. The bots
also run when a commit is pushed to the master branch, similarly to the
existing Buildbot setup. You can see the libc++ pipeline in action here:
https://buildkite.com/llvm-project/libcxx-ci.
This is great -- we’ve been waiting to set up pre-commit CI for a long
time, and we’ve seen a giant productivity gain since it’s up. I think
everyone who contributes to libc++ greatly benefits, seeing how reviews are
now used to trigger CI and improve our confidence in changes.
This change does have an impact on existing build bots that are not owned
by one of the libc++ maintainers. While I transferred the build bots that
we owned (which Eric had set up) to Buildkite, the remaining build bots
will have to be moved to Buildkite by their respective owners. These builds
bots are (owners in CC):
libcxx-libcxxabi-x86_64-linux-debian
libcxx-libcxxabi-x86_64-linux-debian-noexceptions
libcxx-libcxxabi-libunwind-x86_64-linux-debian
libcxx-libcxxabi-singlethreaded-x86_64-linux-debian
libcxx-libcxxabi-libunwind-armv7-linux
libcxx-libcxxabi-libunwind-armv8-linux
libcxx-libcxxabi-libunwind-armv7-linux-noexceptions
libcxx-libcxxabi-libunwind-armv8-linux-noexceptions
libcxx-libcxxabi-libunwind-aarch64-linux
libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions
The process of moving these bots over to Buildkite is really easy. Please
take a look at the documentation at
https://libcxx.llvm.org/docs/AddingNewCIJobs.html#addingnewcijobs and
contact me if you need additional help.
To make sure we get the full benefits of pre-commit CI soon, I would like
to put a cutoff date on supporting the old libc++ builders at
http://lab.llvm.org:8011/builders. I would propose that after January 1st
2021 (approx. 1 month from now), the libc++ specific build bots at
lab.llvm.org be removed in favor of the Buildkite ones. If you currently
own a bot, please make sure to add an equivalent Buildkite bot by that
cutoff date to make sure your configuration is still supported, or let me
know if you need an extension.
Furthermore, with the ease of creating new CI jobs with this
infrastructure, we will consider any libc++ configuration not covered by a
pre-commit bot as not explicitly supported. It doesn’t mean that such
configurations won’t work -- it just means that we won’t be making bold
claims about supporting configurations we’re unable to actually test. So if
you care about a configuration, please open a discussion and let’s see how
we can make sure it's tested properly!
I am thrilled to be moving into the pre-commit CI era. The benefits we see
so far are huge, and we're loving it.
Thanks,
Louis
PS: This has nothing to do with a potential move or non-move to GitHub. The
current pre-commit CI works with Phabricator, and would work with GitHub if
we decided to switch. Let’s try to keep those discussions separate :-).
PPS: We’re still aiming to support non libc++ specific Buildbots. For
example, if something in libc++ breaks a Clang bot, we’ll still be
monitoring that. I’m just trying to move the libc++-specific configurations
to pre-commit.
[VIRT-349 # QEMU SVE2 Support ]
I have a working FVP SVE2 install!
I used a new FVP version (11.13.36) from the last time that I tried (11.13.21
on Jan 27).
I used a debian-testing snapshot from 1-MAR, which has linux 5.10 bundled, and
fvp revc dtb installed.
I used
https://git.linaro.org/landing-teams/working/arm/arm-reference-platforms.gi…
(which is linked to by one of the howtos that Peter forwarded) and chose the
"pre-built uefi" version. I need to report a bug on this build script -- the
"build from source" option does not work on a system that has all python3 and
no python2.
I've rebuilt all of the risu trace files for vq=4 (512-bit).
I'm now refreshing my qemu branch to test.
[UM-61 # TCG Core Maintainership ]
PR for patch queue; aa64 fixes, tci fixes, tb_lookup cleanups.
[UM-2 # Upstream Maintainership ]
Patch review, mostly v8.1m board stuff.
r~
Progress (short week, 2 days):
* Some time spent on setting up new work laptop
* Started in on the pile of code review that had built up
while I was on holiday... made a bit of progress and sent out
one pullreq. Queue length now: 16 series.
thanks
-- PMM
Hi, all
Does anybody know what does '.....isra.0' mean in GCC 10.2 compiled objects?
I just noticed this issue when using bcc/eBPF tools. I submitted the detail
into
* https://github.com/iovisor/bcc/issues/3293
Simply put, when building a linux kernel with GCC 10.2, the symbol
'finish_task_switch' becomes 'finish_task_switch.isra.0' in the object (as
reported by 'nm')
Because a lot of kernel tracers (such as bcc) use 'finish_task_switch' as
the probe point, this change in the compilation result can make all result
such tools fail.
Thanks.
Best regards,
Guodong Xu
== Progress ==
* GCC upstream validation:
- a couple of regressions to bisect.
- minor testcase fix
- reported a couple of new failures
* GCC
- MVE autovectorization:
- vcmp support mostly complete. Minor update needed to support FP types.
- working on interleaved vector load/store support
* Misc
- fixed stm32 benchmarking harness, it's working again.
- submitted patches to reduce the toolchain build time (for
benchmarking we don't need all multilibs which take ages to build)
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Hi
I've been trying to run clang on a Windows on Arm machine, but it keeps trying to using the link.exe located in "Visual studio/..../Host64/arm64", which is (seemingly) an x64 tool and as such doesn't run, and crashes the process.
Is there a way to set clang to look at VS's x86 link.exe? Or if there is an arm64 version that clang should be using instead?
Thanks,
Joel
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Hi,
I've been trying to use clang on Windows on Arm machine (Samsung Galaxy Book S), but whenever I try to use it, I get either nothing (in powershell) or an error popup: "The application was unable to start correctly (0x000007b)".
The release I'm using is LLVM-12.0.0-rc1-woa64.exe<https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.0-rc1/L…> from https://github.com/llvm/llvm-project/releases/tag/llvmorg-12.0.0-rc1
I have a feeling there might be a library or dependency I am missing.
Any help with how to resolve this issue would be appreciated.
Thanks,
Joel
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
[UM-2 # QEMU Upstream Work]
* A lot of patch review.
* Some target/i386 cleanup, as followup to said patch review.
* Collecting patches for tcg-next.
r~
== Progress ==
* GCC upstream validation:
- a few regressions to bisect. Fixed a minor testcase issue
* GCC
- MVE autovectorization: Working on vcmp. After some cleanup &
factorization, the cmp operators work on GCC vectors. I will now
resume work on auto-vectorization.
* Misc
- fixes in stm32 benchmarking harness
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
* After proving that the aarch64 host problem with
booting s390x with virtio was lack of barriers for
the guest memory model, I've spent some time working
on a ld-acq/st-rel optimizer for tcg.
* Minor rev of tci rewrite.
* Some patch review on claudio's kvm/tcg split.
r~
Progress:
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ sent out v2 of the MPS3-AN524 series (minor changes only)
+ discovered that I need to implement the SSE-300's System Counter
+ implemented the system counter, did some final testing and
reviewing, and sent out v1 of the MPS3-AN547 series to the list
+ once these patches are reviewed and in master the QEMU-413 epic
will be complete
-- PMM
Hello Linaro Toolchain Working Group,
libcxx-libcxxabi-libunwind-armv8-linux has been red for 5 days.
clang-cmake-aarch64-global-isel has been red for 10 days.
clang-cmake-aarch64-quick has been red for 10 days.
clang-cmake-armv7-global-isel has been red for 10 days.
clang-cmake-armv7-lnt has been red for 10 days.
clang-cmake-aarch64-lld has been red for 11 days.
clang-cmake-armv8-lld has been red for 11 days.
clang-cmake-thumbv7-full-sh has been red for 11 days.
clang-cmake-armv7-full has been red for 11 days.
Is anybody looking at this?
I also noticed that some of your workers are less reliable than others. For
example, inaro-tk1-09 worker was last time producing a green build 2 months
ago - http://lab.llvm.org:8011/#/workers/2?numbuilds=500
I'm removing the linaro-tk1-09 worker from the production buildbot for now.
Please feel free to connect it to the staging and make the builder reliably
green. Then it could be returned back to the production.
linaro-armv8-windows-msvc-01 and linaro-armv8-windows-msvc-02 have been red
for the least 4 months. I'm removing them from the production buildbot. You
can return them back to production after they are reliably green in the
staging.
Please feel free to ask if you have questions.
Thanks
Galina
== Progress ==
* GCC upstream validation:
- a few regressions to bisect. Fixed a minor testcase issue
- native validation in Linaro's lab: we still see a few random results
* GCC
- MVE autovectorization: Working on vcmp.
* Misc
- fixes in stm32 benchmarking harness
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Holidays next week, back Monday 22nd Feb
Progress:
* UM-2 [QEMU upstream maintainership]
+ sent out a small code-cleanup patchset for some arm display device
models to remove no-longer-needed support for non-32bpp outputs
+ tracked down (with the aid of Paolo) why our build system had started
building the documentation every time you run 'make'; sent a fix
+ code review todo queue status: 12 items, but the oldest was only
sent to the list on Monday...
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ An MPS3 Cortex-M55 FPGA image is now publicly available: the AN547.
We'll provide a model of this in QEMU. Started working on the
patchseries to implement it (relatively small changes on top of
the SSE-300 work I've already done but not sent out, and the
mps3-an524 series I sent out for review last week). This is basically
code-complete but I need to do some more testing and ideally I'd
like the AN524 series to get reviewed before I send out another
40-patch series that would have to be based on top of that one.
thanks
-- PMM
Hello,
I've uploaded binaries for Windows on Arm:
081373cc76e88224020fea42eba2161d972f03bb83ebc055fb3cd4f2cfcdfb95
LLVM-12.0.0-rc1-woa64.exe
It was built from the current release/12.x branch (commit b46924ee) with
two patches applied on top:
- https://reviews.llvm.org/D96259
- https://reviews.llvm.org/D96498
It contains "clang;clang-tools-extra;lld;compiler-rt” projects.
Compiler-RT has sanitizers disabled (MEMPROF and XRAY use sanitizer
infrastucture). I.e.,
===
+ -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra;lld;compiler-rt" ^
+ -DCOMPILER_RT_BUILD_SANITIZERS=OFF ^
+ -DCOMPILER_RT_BUILD_MEMPROF=OFF ^
+ -DCOMPILER_RT_BUILD_XRAY=OFF ^
===
I've attached the changes we had to make to
llvm/utils/releases/build_llvm_package.bat. @Maxim Kuvyrkov is going to
clean them up and post a patch in the next couple of weeks (he's been doing
all the hard work, I'm just uploading).
This is the first time we're trying to provide a release for Windows on
Arm, so if anyone has any comments or questions, feel free to send an email
:)
Cheers,
Diana
On Thu, 28 Jan 2021 at 05:05, Tom Stellard via lldb-dev <
lldb-dev(a)lists.llvm.org> wrote:
> Hi,
>
> I've tagged the 12.0.0-rc1 release. Testers can begin testing and upload
> binaries.
>
> -Tom
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev(a)lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
VirtIO Initiative ([STR-9])
===========================
- TSC Stratos next cycle presentation
- [Stratos Sync - this week discussing Rust]
- Followed up on Rust presentation and sketched out some areas of
interest
[STR-9] <https://projects.linaro.org/browse/STR-9>
[Stratos Sync - this week discussing Rust]
<https://collaborate.linaro.org/display/STR/2021-02-04+Project+Stratos+Sync+…>
QEMU Support for Xen ([STR-20])
===============================
- latest iteration of [PATCH V6 00/24] IOREQ feature (+ virtio-mmio)
on Arm Message-Id:
<1611884932-1851-1-git-send-email-olekstysh(a)gmail.com>
- while re-basing [my Xen loader and fixes tree]
- realised that [PATCH v4 00/12] Support disabling TCG on ARM (part
2) Message-Id: <20200929224355.1224017-1-philmd(a)redhat.com> would
be useful
- which awaits [PATCH v14 00/22] i386 cleanup PART 2 Message-Id:
<20210128092814.8676-1-cfontana(a)suse.de> being merged
- bunch of related review of pre-cursor stuff
[STR-20] <https://projects.linaro.org/browse/STR-20>
[my Xen loader and fixes tree]
<https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…>
QEMU Upstream Work ([UM-2])
===========================
- caught up on a bunch of review
- got about halfway through rth's mega TCI series
- posted [PATCH v1 00/15] testing/gdbstub/docs pre-PR Message-Id:
<20210202134001.25738-1-alex.bennee(a)linaro.org>
- will roll PR on Monday
- some discussion on Detecting Faulting Instructions From Plugins
Message-Id: <YBTRSK4/F5KLH+FZ(a)strawberry.localdomain>
- looks like we need special handling for instrumentation on
recompiled IO ops
[UM-2] <https://projects.linaro.org/browse/UM-2>
Completed Reviews [5/5]
=======================
[PATCH 00/10] target: Provide target-specific Kconfig
Message-Id: <20210131111316.232778-1-f4bug(a)amsat.org>
[PATCH v3 0/5] Fix some style problems in contrib
Message-Id: <20210118031004.1662363-1-zhouyang789(a)huawei.com>
[PATCH v15 00/23] i386 cleanup PART 2
Message-Id: <20210201100903.17309-1-cfontana(a)suse.de>
[PATCH 00/22] Acceptance Test: introduce base class for Linux based tests
Message-Id: <20210203172357.1422425-9-crosa(a)redhat.com>
[PATCH v2 0/5] Move remaining x86 Travis jobs to the gitlab-CI
Message-Id: <20210205091857.845389-1-thuth(a)redhat.com>
Absences
========
- Lockdown 3: Home schooling returns!
Current Review Queue
====================
* [PATCH v6 00/11] Support disabling TCG on ARM (part 2)
Message-Id: <20210131115022.242570-1-f4bug(a)amsat.org>
Added: <2021-01-31 Sun>
* [PATCH V6 00/24] IOREQ feature (+ virtio-mmio) on Arm
Message-Id: <1611884932-1851-1-git-send-email-olekstysh(a)gmail.com>
Added: <2021-01-29 Fri>
* [RFC PATCH 0/4] hw/intc: enable GICv4 memory layout for GICv3 driver
Message-Id: <20210124025306.3949-1-leif(a)nuviainc.com>
Added: <2021-01-25 Mon>
--
Alex Bennée
== Progress ==
* GCC upstream validation:
- not really catching up, now ~15 days late due to the numerous
commits. Manually fast-forwarded the latest build to today. I'll
bisect manually for regressions if needed.
- re-enabled native validation in Linaro's lab: we are sending test
results again
* GCC
- MVE autovectorization: vorn patch committed. Working on vcmp.
== Next ==
* MVE auto-vectorization/intrinsics improvements
* GCC/cortex-M testing improvements & fixes
* cortex-m benchmarking
Progress:
* UM-2 [QEMU upstream maintainership]
+ lots of code review this week, including another round of rth's
MTE user-mode patchset
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ Sent out an RFC proposing some more Clock API changes (since it'll
be a while before I'm ready to post the series with the new timer
device that requires them)
+ The SSE-200 Cortex-M33-based MPS3 AN524 FPGA image is a useful
target to model: the Zephyr folks would like it, and it is a good
stepping stone to an MPS3 FPGA image with a Cortex-M55/SSE-300 in
it. Wrote a patchset for an mps3-an524 board model, and sent it out
for review.
-- PMM
Please see
https://lists.ubuntu.com/archives/ubuntu-devel/2021-January/041341.htmlhttps://wiki.ubuntu.com/ToolChain/LTO
Some builds only fail on AArch64, these are:
buildlog_ubuntu-hirsute-arm64.abiword_3.0.4~dfsg-2_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.adabrowse_4.0.3-12_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.adacontrol_1.21r6b-5_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.armnn_19.11.1-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.cctools_7.1.2-2ubuntu3_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.csound_1:6.14.0~dfsg-6build1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.dh-ada-library_6.20_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.dietlibc_0.34~cvs20160606-12_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.entropybroker_2.9-3build2_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.fpc_3.2.0+dfsg-8build2_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.grcompiler_5.2-2.1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.haskell-hopenpgp-tools_0.23.1-1build2_BUILDING.txt.gz
arm64
buildlog_ubuntu-hirsute-arm64.ignition-common_3.5.0+dfsg1-4_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.lazarus_2.0.10+dfsg-4_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.lepton-eda_1.9.13-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.libcxx-serial_1.2.1-4_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.minetest_5.3.0+repack-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.ogre-1.12_1.12.5+dfsg1-1ubuntu1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.openmsx_16.0-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.parsinsert_1.04-7ubuntu1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.prometheus-alertmanager_0.21.0+ds-2build1_BUILDING.txt.gz
arm64
buildlog_ubuntu-hirsute-arm64.pyqt5_5.15.2+dfsg-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.racon_1.4.13-2build1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.rampler_1.1.1-3_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.ruby-http-parser.rb_0.6.0-5_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.shasta_0.6.0-4build1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.snd_20.9-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.sogo_4.3.2-1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.swiglpk_4.65.0-2build3_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.synfig_1.2.2+dfsg-3build3_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.synfigstudio_1.2.2-1build1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.tcc_0.9.27+git20200814.62c30a4a-1_BUILDING.txt.gz
arm64
buildlog_ubuntu-hirsute-arm64.unar_1.10.1-2build9_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.valgrind_1:3.16.1-1ubuntu1_BUILDING.txt.gz arm64
buildlog_ubuntu-hirsute-arm64.vulkan-tools_1.2.154.0+dfsg1-1_BUILDING.txt.gz arm64
Note that some of those like the Ada related ones are false positives, and I
didn't look at the arm64 specific issues yet.
All builds were done using the GCC 10 branch.
Matthias
VirtIO Initiative ([STR-9])
===========================
- some prep for next weeks TSC
QEMU Device and Machine Models ([QEMU-418])
===========================================
- added a bunch of new cards for ARMv8.7 features using ARMs new
feature type
QEMU Support for Xen ([STR-20])
===============================
- latest iteration of [PATCH V6 00/24] IOREQ feature (+ virtio-mmio)
on Arm Message-Id:
<1611884932-1851-1-git-send-email-olekstysh(a)gmail.com>
- while re-basing [my Xen loader and fixes tree]
- realised that [PATCH v4 00/12] Support disabling TCG on ARM (part
2) Message-Id: <20200929224355.1224017-1-philmd(a)redhat.com> would
be useful
- which awaits [PATCH v14 00/22] i386 cleanup PART 2 Message-Id:
<20210128092814.8676-1-cfontana(a)suse.de> being merged
[STR-20] <https://projects.linaro.org/browse/STR-20>
[my Xen loader and fixes tree]
<https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…>
QEMU Upstream Work ([UM-2])
===========================
- posted [PATCH v1 0/2] meson fixups for check-tcg/softfloat
Message-Id: <20210126145356.7860-1-alex.bennee(a)linaro.org>
- posted some documentation patches while helping LKFT team get up and
running
- [PATCH] docs/system: document an example vexpress-a15 invocation
Message-Id: <20210128185300.2875-1-alex.bennee(a)linaro.org>
[UM-2] <https://projects.linaro.org/browse/UM-2>
Completed Reviews [3/3]
=======================
[PATCH v4 0/4] meson: Try to clarify TCG / TCI options for new users
Message-Id: <8f1f2dc6-5ad2-7d48-c2f9-9afa1e4d4065(a)weilnetz.de>
[PATCH 00/23] TCI fixes and cleanups
Message-Id: <20210128082331.196801-1-richard.henderson(a)linaro.org>
[PATCH] accel/tcg: Add URL of clang bug to comment about our workaround
Message-Id: <20210129130330.30820-1-peter.maydell(a)linaro.org>
Absences
========
- Lockdown 3: Home schooling returns!
Current Review Queue
====================
* [PATCH V6 00/24] IOREQ feature (+ virtio-mmio) on Arm
Message-Id: <1611884932-1851-1-git-send-email-olekstysh(a)gmail.com>
Added: <2021-01-29 Fri>
* [RFC PATCH 0/4] hw/intc: enable GICv4 memory layout for GICv3 driver
Message-Id: <20210124025306.3949-1-leif(a)nuviainc.com>
Added: <2021-01-25 Mon>
* [PATCH v3 00/21] target-arm: Implement ARMv8.5-MemTag, user mode
Message-Id: <20210115224645.1196742-1-richard.henderson(a)linaro.org>
Added: <2021-01-18 Mon>
* [PATCHv3 00/17] ARMv8.4 Secure EL2
Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net>
Added: <2020-12-08 Tue>
--
Alex Bennée
Progress:
* UM-2 [QEMU upstream maintainership]
+ usual upstream maintenance, code review, etc
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ CMSDK Clock changes now upstream
+ When integrating those with the SSE timer model, found what seem like
some more clock API changes we could use; patches in progress
Some Arm-internal training and similar admin tasks this week.
thanks
-- PMM
[UM-61 TCG Maint]
3 different attempts at fixing the out-of-temps
failure produced by the tcg-constant patch set.
The last, longjmp to restart w/ a smaller tb,
seems unlikely to have unanticipated side effects.
[UM-2 QEMU Maint]
Refresh two patches toward cortex-a76.
Misc patch review.
Partial fix for target/ppc mis-use of tb->flags.
r~
VirtIO Initiative ([STR-9])
===========================
- posted Project Stratos planning priorities for the next development
cycle (-> Oct2021) Message-Id: <87im7rtpyq.fsf(a)linaro.org>
- baring feedback from members during voting I think this is what we
are doing
- attended [AGL discussion] on zero-copy for virtio-gpu with Peter
Griffin
- more meetings on other collaboration opportunities, drew more slide
ware
- bootstrapped my RB5 rig, just need to figure out how to update the
kernel
[STR-9] <https://projects.linaro.org/browse/STR-9>
[AGL discussion]
<https://confluence.automotivelinux.org/display/VE/Meeting+Agenda?src=contex…>
QEMU Device and Machine Models ([QEMU-418])
===========================================
- flurry of syncing and card creation, solidified [QEMU-414]
[QEMU-418] <https://projects.linaro.org/browse/QEMU-418>
[QEMU-414] <https://projects.linaro.org/browse/QEMU-414>
QEMU Support for Xen ([STR-20])
===============================
- continued looking at [PATCH V4 00/24] IOREQ feature (+ virtio-mmio)
on Arm Message-Id:
<1610488352-18494-1-git-send-email-olekstysh(a)gmail.com>
[STR-20] <https://projects.linaro.org/browse/STR-20>
QEMU Upstream Work ([UM-2])
===========================
- respun [PULL v2 00/30] testing, gdbstub and semihosting Message-Id:
<20210118111745.20104-1-alex.bennee(a)linaro.org> to fix NetBSD issue
- posted [PATCH v1 0/6] testing/next (docker binfmt tests) Message-Id:
<20210119175208.763-1-alex.bennee(a)linaro.org>
- posted [PATCH v2 0/8] testing/next (docker, binfmt, gdb version)
Message-Id: <20210122181854.23105-1-alex.bennee(a)linaro.org>
[UM-2] <https://projects.linaro.org/browse/UM-2>
Completed Reviews [4/4]
=======================
[PATCH] util/log: flush TB cache when log level changes
Message-Id: <161130982491.1038646.15688151175539344664.stgit@pasha-ThinkPad-X280>
[PATCH v3] hw/core/qdev-properties-system: Rewrite set_pci_host_devaddr using GLib
Message-Id: <20201125083300.861206-1-philmd(a)redhat.com>
[RFC PATCH] tests/docker: Allow passing --network option when building images
Message-Id: <20210119054502.531451-1-f4bug(a)amsat.org>
[PATCH] tcg: Increase the static number of temporaries
Message-Id: <20210121025439.1120405-1-richard.henderson(a)linaro.org>
Absences
========
- Lockdown 3: Home schooling returns!
Current Review Queue
====================
* [PATCH v3 00/21] target-arm: Implement ARMv8.5-MemTag, user mode
Message-Id: <20210115224645.1196742-1-richard.henderson(a)linaro.org>
Added: <2021-01-18 Mon>
* [PATCH 0/6] accel: Restrict TCG-specific code
Message-Id: <20210117164813.4101761-1-f4bug(a)amsat.org>
Added: <2021-01-18 Mon>
* [PATCH V4 00/24] IOREQ feature (+ virtio-mmio) on Arm
Message-Id: <1610488352-18494-1-git-send-email-olekstysh(a)gmail.com>
Added: <2021-01-13 Wed>
* [PATCH v5 00/23] tcg: Better handling of constants
Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org>
Added: <2020-12-17 Thu>
--
Alex Bennée
Progress:
* UM-2 [QEMU upstream maintainership]
+ Code review (including RTH's MTE-for-user-mode-emulation)
+ Investigating an intermittent failure of a test case involving
an s390 guest on aarch64 hosts...
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ Converted the ARMSSE (IoTKit/SSE-200) code over to use the Clock
framework, which was added to QEMU after ARMSSE was first written.
(This is a prereq for adding the new-in-SSE-300 timer device, which
will use Clocks.) Sent the patches out for review.
I'm currently experimenting with a schedule of:
Mon: JIRA task work; Tue: code review; Thu: JIRA task work; Fri: misc upstream
thanks
-- PMM
Adding the Linaro toolchain group mailing list.
On Mon, Jan 18, 2021 at 05:49:39PM +0300, Sergey Suloev wrote:
> Hi, guys,
>
> I am having an issue builduing kernel 5.11 (rc4) with Linaro ARM toolchain.
> The issue seems to be related to CC plugins sources.
> Here is my build log: https://pastebin.com/DTn7Szax. I have never seen this
> before with versions 5.10 and below.
>
> Thank you,
> Sergey
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Progress:
* UM-2 [QEMU upstream maintainership]
+ code review, pullreq
+ fixed the "breaks a gitlab CI run" issue with the 'merge docs into
a single sphinx manual' patch
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ Progress with the SSE-300 model:
- finished model of new timer device
- updated iotkit-sysctl register block with SSE-300 specific behaviour
- implemented simple dummy model of new CPU<N>_PWRCTRL register block
- made sse-300 code more data-driven so it can handle sse-300 putting
some of the devices at different places
thanks
-- PMM
Progress (2 day week this week):
* UM-2 [QEMU upstream maintainership]
+ Unsurprisingly, pretty much just catching up with email, pull requests,
code review, bug reports, respins of patchsets...
* QEMU-364 [QEMU support for ARMv8.1-M extensions]
+ The final parts of base v8.1M and Cortex-M55 support are now in master.
thanks
-- PMM
(or the 10 days preceding Christmas)
[UM-61 TCG Maint]
New version of tcg constants patch set.
TCG backend constraints cleanup.
ARM NEON host patch set.
[UM-2 QEMU Maint]
Fixed tcg gvec bug vs hosts without vector support.
Rebase and re-send pauth impdef algorithm.
Patch review: mips, riscv. gdbstub.
r~
VirtIO RPMB ([STR-5])
=====================
- Continued working on Rust port of vhost-user-rpmb
- Re-based and updated the [QEMU based branch]
[QEMU based branch]
<https://github.com/stsquad/qemu/tree/virtio/vhost-user-rpmb-v2>
QEMU Support for Xen ([STR-20])
===============================
- re-based and continued to work on Xen development environment
- with my [current branch] I can now boot domU inside dom0
- also can now run qemu-aarch64 as a Dom0 PV backend
[branch to clean-up and add "virt" machine]
<https://github.com/stsquad/qemu/tree/xen/add-xen-virt-machine>
[current branch]
<https://github.com/stsquad/qemu/tree/xen/guest-loader-and-arm-build-cleanup…>
QEMU Device and Machine Models ([QEMU-418])
===========================================
- created new initiative for tracking work both in and outside group
- we don't want another watchdog duplication
- worked on refining definition for [CPU model for QEMU]
- wrote to Linaro open discussion list to canvas members
requirements Message-Id: <878saesi0x.fsf(a)linaro.org>
[QEMU-418] <https://projects.linaro.org/browse/QEMU-418>
[CPU model for QEMU] <https://projects.linaro.org/browse/QEMU-414>
QEMU Upstream Work ([UM-2])
===========================
- posted [RFC PATCH] configure: add --without-default-features
Message-Id: <20201202153827.17446-1-alex.bennee(a)linaro.org>
- posted [PATCH v2 0/8] testing/next (without-features, gitlab,
python) Message-Id: <20201210190417.31673-1-alex.bennee(a)linaro.org>
- posted [PATCH v1 0/6] gdbstub (auxv, tests, cleanup) Message-Id:
<20201214153012.12723-6-alex.bennee(a)linaro.org>
- posted [PULL 00/11] testing and configure updates Message-Id:
<20201216164827.24457-1-alex.bennee(a)linaro.org>
- posted [PULL v2 00/11] testing and configure updates Message-Id:
<20201217094330.17400-1-alex.bennee(a)linaro.org>
- still stalled due to some stale build issues (unable to repro)
- posted [PATCH v2 0/9] gdbstub/next (cleanups, softmmu, SVE)
Message-Id: <20201218112707.28348-1-alex.bennee(a)linaro.org>
[UM-2] <https://projects.linaro.org/browse/UM-2>
Other work
==========
- bootstrapped gitdm metadata for GCC project
- planning for Stratos/QEMU Next Cycle
- declared bankruptcy on my review queue, flushed most of it
Completed Reviews [5/5]
=======================
[PATCH v4 00/11] hvf: Implement Apple Silicon Support
Message-Id: <20201203234857.21051-2-agraf(a)csgraf.de>
[RFC v9 00/22] i386 cleanup
Message-Id: <20201208194839.31305-1-cfontana(a)suse.de>
[PATCH 0/3] hw/arm: sabrelite: Improve emulation fidelity to allow booting upstream U-Boot
Message-Id: <1607937538-69471-1-git-send-email-bmeng.cn(a)gmail.com>
[PATCH 0/2] Fix test-char reference counting bug
Message-Id: <20201215224133.3545901-1-ehabkost(a)redhat.com>
[PATCH 0/8] Add RISC-V semihosting 0.2. Finish ARM semihosting 2.0
Message-Id: <20201125213617.2496935-1-keithp(a)keithp.com>
Absences
========
- Back on Jan 5th, Happy Christmas
Current Review Queue
====================
* [PATCH v5 00/23] tcg: Better handling of constants
Message-Id: <20201217145215.534637-1-richard.henderson(a)linaro.org>
Added: <2020-12-17 Thu>
* [PATCHv3 00/17] ARMv8.4 Secure EL2
Message-Id: <3333301.iIbC2pHGDl(a)basile.remlab.net>
Added: <2020-12-08 Tue>
* [PATCH v2 0/7] xen/arm: Unbreak ACPI
Message-Id: <20201023154156.6593-1-julien(a)xen.org>
Added: <2020-10-24 Sat>
* [PATCH v6 0/5] Enable plugin support on msys2/mingw
Message-Id: <20201013002806.1447-1-luoyonggang(a)gmail.com>
Added: <2020-10-13 Tue>
--
Alex Bennée
== This Week ==
* PR97872 (missed optimization for comparison on vectors)
- Committed fix to trunk
* PR97903 (Lower a & b != 0 to vtst)
- In progress
* PR66791 (Replace builtins by vector extensions in arm_neon.h intrinsics)
- Committed patches for vmvn
- Patches approved for vcreate, vneg, vclt, vcgt.
== Next Week ==
- PR97903
- PR66791: Commit approved patches and work on new intrinsics
Progress:
* UM-2 [QEMU upstream maintainership]
+ sent out a pullreq for 6.0, and did a bunch more patch review
+ sent out a respin of the "build one manual, not five" RFC I sent last
month; nobody objected to the RFC so this time around it is a proper
PATCH
+ had a brief scan through the GIC architecture specification to look
at what extra GICv4 and GICv4.1 add (the big thing is that the ITS is
now mandatory; QEMU doesn't emulate that yet)
* VIRT-364 [QEMU support for ARMv8.1-M extensions]
+ SSE-300 timer device model more or less functionally-complete (though
untested). I ran into some issues with QEMU's Clock APIs that I needed
to fix in the process -- sent a patchseries trying to address those.
+ Got most of the outstanding v8.1M patches into master; sent a small
patch series with respins of the last 4 or so patches that needed
more work
thanks
-- PMM