(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