linaro-toolchain February 2023

linaro-toolchain@lists.linaro.org

8 participants
14 discussions

by Mark de Wever

Hi, As discussed in [1] I just committed [2] to update the minimum CMake version in LLVM to 3.20.0. Unfortunately it seems the ARM builders in the libc++ precommit CI are running CMake 3.16.3 [3]. Would it be possible to update these builders? [1] https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-cmake-ver… [2] https://reviews.llvm.org/D144509a [3] https://buildkite.com/llvm-project/libcxx-ci/builds/19366#0186756a-1599-46e… Thanks, Mark

8 months, 1 week

[TCWG CI] Failure after llvmorg-17-init-3239-g025952b00e0d: [X86] Add PR46472 bitselect test coverage

by ci_notify＠linaro.org

Failure after llvmorg-17-init-3239-g025952b00e0d: [X86] Add PR46472 bitselect test coverage: Results changed to -10 # build_aosp_toolchain: -2 # build_shadow_llvm: -1 # build_aosp: 0 from -10 # build_aosp_toolchain: -2 # build_shadow_llvm: -1 # build_aosp: 0 THIS IS THE END OF INTERESTING STUFF. BELOW ARE LINKS TO BUILDS, REPRODUCTION INSTRUCTIONS, AND THE RAW COMMIT. For latest status see comments in https://linaro.atlassian.net/browse/GNU-692 . Status of llvmorg-17-init-3239-g025952b00e0d commit for tcwg_aosp-code_size-surfaceflinger: commit 025952b00e0d5392d31387a4ed4e1d342003a37a Author: Simon Pilgrim <llvm-dev(a)redking.me.uk> Date: Sun Feb 26 15:19:46 2023 +0000 [X86] Add PR46472 bitselect test coverage As noted on Issue #45817 we didn't have scalar coverage for this * oriole-master ** Failure after llvmorg-17-init-3239-g025952b00e0d: [X86] Add PR46472 bitselect test coverage: ** https://ci.linaro.org/job/tcwg_aosp-code_size-surfaceflinger--oriole-master… Bad build: https://ci.linaro.org/job/tcwg_aosp-code_size-surfaceflinger--oriole-master… Good build: https://ci.linaro.org/job/tcwg_aosp-code_size-surfaceflinger--oriole-master… Reproduce current build: <cut> mkdir -p investigate-llvm-025952b00e0d5392d31387a4ed4e1d342003a37a cd investigate-llvm-025952b00e0d5392d31387a4ed4e1d342003a37a # Fetch scripts git clone https://git.linaro.org/toolchain/jenkins-scripts # Fetch manifests for bad and good builds mkdir -p bad/artifacts good/artifacts curl -o bad/artifacts/manifest.sh https://ci.linaro.org/job/tcwg_aosp-code_size-surfaceflinger--oriole-master… --fail curl -o good/artifacts/manifest.sh https://ci.linaro.org/job/tcwg_aosp-code_size-surfaceflinger--oriole-master… --fail # Reproduce bad build (cd bad; ../jenkins-scripts/tcwg_aosp-build.sh ^^ true %%rr[top_artifacts] artifacts) # Reproduce good build (cd good; ../jenkins-scripts/tcwg_aosp-build.sh ^^ true %%rr[top_artifacts] artifacts) </cut> Full commit (up to 1000 lines): <cut> commit 025952b00e0d5392d31387a4ed4e1d342003a37a Author: Simon Pilgrim <llvm-dev(a)redking.me.uk> Date: Sun Feb 26 15:19:46 2023 +0000 [X86] Add PR46472 bitselect test coverage As noted on Issue #45817 we didn't have scalar coverage for this --- llvm/test/CodeGen/X86/bitselect.ll | 202 +++++++++++++++++++++++++++++++++++++ 1 file changed, 202 insertions(+) diff --git a/llvm/test/CodeGen/X86/bitselect.ll b/llvm/test/CodeGen/X86/bitselect.ll new file mode 100644 index 000000000000..5f1f6bd83a9a --- /dev/null +++ b/llvm/test/CodeGen/X86/bitselect.ll @@ -0,0 +1,202 @@ +; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py +; RUN: llc < %s -mtriple=i686-unknown-unknown | FileCheck %s --check-prefixes=X86 +; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=-bmi | FileCheck %s --check-prefixes=X64,X64-NOBMI +; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+bmi | FileCheck %s --check-prefixes=X64,X64-BMI + +; PR46472 +; bitselect(a,b,m) == or(and(a,not(m)),and(b,m)) +; bitselect(a,b,m) == xor(and(xor(a,b),m),a) + +define i8 @bitselect_i8(i8 %a, i8 %b, i8 %m) nounwind { +; X86-LABEL: bitselect_i8: +; X86: # %bb.0: +; X86-NEXT: movzbl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: movzbl {{[0-9]+}}(%esp), %eax +; X86-NEXT: xorb %cl, %al +; X86-NEXT: andb {{[0-9]+}}(%esp), %al +; X86-NEXT: xorb %cl, %al +; X86-NEXT: retl +; +; X64-LABEL: bitselect_i8: +; X64: # %bb.0: +; X64-NEXT: andl %edx, %esi +; X64-NEXT: movl %edx, %eax +; X64-NEXT: notb %al +; X64-NEXT: andb %dil, %al +; X64-NEXT: orb %sil, %al +; X64-NEXT: retq + %not = xor i8 %m, -1 + %ma = and i8 %a, %not + %mb = and i8 %b, %m + %or = or i8 %ma, %mb + ret i8 %or +} + +define i16 @bitselect_i16(i16 %a, i16 %b, i16 %m) nounwind { +; X86-LABEL: bitselect_i16: +; X86: # %bb.0: +; X86-NEXT: movzwl {{[0-9]+}}(%esp), %eax +; X86-NEXT: movzwl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: xorw %ax, %cx +; X86-NEXT: andw {{[0-9]+}}(%esp), %cx +; X86-NEXT: xorl %ecx, %eax +; X86-NEXT: # kill: def $ax killed $ax killed $eax +; X86-NEXT: retl +; +; X64-NOBMI-LABEL: bitselect_i16: +; X64-NOBMI: # %bb.0: +; X64-NOBMI-NEXT: movl %edx, %eax +; X64-NOBMI-NEXT: andl %edx, %esi +; X64-NOBMI-NEXT: notl %eax +; X64-NOBMI-NEXT: andl %edi, %eax +; X64-NOBMI-NEXT: orl %esi, %eax +; X64-NOBMI-NEXT: # kill: def $ax killed $ax killed $eax +; X64-NOBMI-NEXT: retq +; +; X64-BMI-LABEL: bitselect_i16: +; X64-BMI: # %bb.0: +; X64-BMI-NEXT: andnl %edi, %edx, %eax +; X64-BMI-NEXT: andl %edx, %esi +; X64-BMI-NEXT: orl %esi, %eax +; X64-BMI-NEXT: # kill: def $ax killed $ax killed $eax +; X64-BMI-NEXT: retq + %not = xor i16 %m, -1 + %ma = and i16 %a, %not + %mb = and i16 %b, %m + %or = or i16 %ma, %mb + ret i16 %or +} + +define i32 @bitselect_i32(i32 %a, i32 %b, i32 %m) nounwind { +; X86-LABEL: bitselect_i32: +; X86: # %bb.0: +; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: movl {{[0-9]+}}(%esp), %eax +; X86-NEXT: xorl %ecx, %eax +; X86-NEXT: andl {{[0-9]+}}(%esp), %eax +; X86-NEXT: xorl %ecx, %eax +; X86-NEXT: retl +; +; X64-NOBMI-LABEL: bitselect_i32: +; X64-NOBMI: # %bb.0: +; X64-NOBMI-NEXT: movl %esi, %eax +; X64-NOBMI-NEXT: xorl %edi, %eax +; X64-NOBMI-NEXT: andl %edx, %eax +; X64-NOBMI-NEXT: xorl %edi, %eax +; X64-NOBMI-NEXT: retq +; +; X64-BMI-LABEL: bitselect_i32: +; X64-BMI: # %bb.0: +; X64-BMI-NEXT: andnl %edi, %edx, %eax +; X64-BMI-NEXT: andl %edx, %esi +; X64-BMI-NEXT: orl %esi, %eax +; X64-BMI-NEXT: retq + %not = xor i32 %m, -1 + %ma = and i32 %a, %not + %mb = and i32 %b, %m + %or = or i32 %ma, %mb + ret i32 %or +} + +define i64 @bitselect_i64(i64 %a, i64 %b, i64 %m) nounwind { +; X86-LABEL: bitselect_i64: +; X86: # %bb.0: +; X86-NEXT: pushl %esi +; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: movl {{[0-9]+}}(%esp), %esi +; X86-NEXT: movl {{[0-9]+}}(%esp), %eax +; X86-NEXT: xorl %ecx, %eax +; X86-NEXT: andl {{[0-9]+}}(%esp), %eax +; X86-NEXT: xorl %ecx, %eax +; X86-NEXT: movl {{[0-9]+}}(%esp), %edx +; X86-NEXT: xorl %esi, %edx +; X86-NEXT: andl {{[0-9]+}}(%esp), %edx +; X86-NEXT: xorl %esi, %edx +; X86-NEXT: popl %esi +; X86-NEXT: retl +; +; X64-NOBMI-LABEL: bitselect_i64: +; X64-NOBMI: # %bb.0: +; X64-NOBMI-NEXT: movq %rsi, %rax +; X64-NOBMI-NEXT: xorq %rdi, %rax +; X64-NOBMI-NEXT: andq %rdx, %rax +; X64-NOBMI-NEXT: xorq %rdi, %rax +; X64-NOBMI-NEXT: retq +; +; X64-BMI-LABEL: bitselect_i64: +; X64-BMI: # %bb.0: +; X64-BMI-NEXT: andnq %rdi, %rdx, %rax +; X64-BMI-NEXT: andq %rdx, %rsi +; X64-BMI-NEXT: orq %rsi, %rax +; X64-BMI-NEXT: retq + %not = xor i64 %m, -1 + %ma = and i64 %a, %not + %mb = and i64 %b, %m + %or = or i64 %ma, %mb + ret i64 %or +} + +define i128 @bitselect_i128(i128 %a, i128 %b, i128 %m) nounwind { +; X86-LABEL: bitselect_i128: +; X86: # %bb.0: +; X86-NEXT: pushl %ebx +; X86-NEXT: pushl %edi +; X86-NEXT: pushl %esi +; X86-NEXT: movl {{[0-9]+}}(%esp), %eax +; X86-NEXT: movl {{[0-9]+}}(%esp), %esi +; X86-NEXT: movl {{[0-9]+}}(%esp), %edx +; X86-NEXT: movl {{[0-9]+}}(%esp), %edi +; X86-NEXT: movl {{[0-9]+}}(%esp), %ebx +; X86-NEXT: movl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: xorl %edi, %ecx +; X86-NEXT: andl {{[0-9]+}}(%esp), %ecx +; X86-NEXT: xorl %edi, %ecx +; X86-NEXT: movl {{[0-9]+}}(%esp), %edi +; X86-NEXT: xorl %ebx, %edi +; X86-NEXT: andl {{[0-9]+}}(%esp), %edi +; X86-NEXT: xorl %ebx, %edi +; X86-NEXT: movl {{[0-9]+}}(%esp), %ebx +; X86-NEXT: xorl %esi, %ebx +; X86-NEXT: andl {{[0-9]+}}(%esp), %ebx +; X86-NEXT: xorl %esi, %ebx +; X86-NEXT: movl {{[0-9]+}}(%esp), %esi +; X86-NEXT: xorl %edx, %esi +; X86-NEXT: andl {{[0-9]+}}(%esp), %esi +; X86-NEXT: xorl %edx, %esi +; X86-NEXT: movl %esi, 12(%eax) +; X86-NEXT: movl %ebx, 8(%eax) +; X86-NEXT: movl %edi, 4(%eax) +; X86-NEXT: movl %ecx, (%eax) +; X86-NEXT: popl %esi +; X86-NEXT: popl %edi +; X86-NEXT: popl %ebx +; X86-NEXT: retl $4 +; +; X64-NOBMI-LABEL: bitselect_i128: +; X64-NOBMI: # %bb.0: +; X64-NOBMI-NEXT: movq %rdx, %rax +; X64-NOBMI-NEXT: xorq %rdi, %rax +; X64-NOBMI-NEXT: andq %r8, %rax +; X64-NOBMI-NEXT: xorq %rdi, %rax +; X64-NOBMI-NEXT: xorq %rsi, %rcx +; X64-NOBMI-NEXT: andq %r9, %rcx +; X64-NOBMI-NEXT: xorq %rsi, %rcx +; X64-NOBMI-NEXT: movq %rcx, %rdx +; X64-NOBMI-NEXT: retq +; +; X64-BMI-LABEL: bitselect_i128: +; X64-BMI: # %bb.0: +; X64-BMI-NEXT: andnq %rsi, %r9, %rsi +; X64-BMI-NEXT: andnq %rdi, %r8, %rax +; X64-BMI-NEXT: andq %r9, %rcx +; X64-BMI-NEXT: orq %rcx, %rsi +; X64-BMI-NEXT: andq %r8, %rdx +; X64-BMI-NEXT: orq %rdx, %rax +; X64-BMI-NEXT: movq %rsi, %rdx +; X64-BMI-NEXT: retq + %not = xor i128 %m, -1 + %ma = and i128 %a, %not + %mb = and i128 %b, %m + %or = or i128 %ma, %mb + ret i128 %or +} </cut>

1 year, 1 month

[ACTIVITY] Report for week #8

by Thiago Jung Bauermann

Hello, # [GNU-796] Stabilize GDB testsuite results in the CI - Cleaned up change in tcwg_gnu-build.sh that reruns failed tests and created Gerrit review request¹. - Based on Laurent's and Maxim's suggestions, decided to put the code which retries the failed tests in Abe, so now I'm working on that. -- Thiago ¹ https://review.linaro.org/c/toolchain/jenkins-scripts/+/43265

1 year, 1 month

[ACTIVITY] report week ending 24 Feb

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] - Code review: big FEAT_LSE2 support series, 8.3 pointer auth, gdbstub support for M-profile sysregs, another round of FEAT_RME, and more - discussions about how to handle the fact that QEMU has run out of gitlab CI minutes, and some tweaking of my scripts to work around the lack of minutes -- PMM

1 year, 1 month

[ACTIVITY] Report for week #7

by Thiago Jung Bauermann

Hello, # [GNU-796] Stabilize GDB testsuite results in the CI - Merged Gerrit review requests removing unsupported and flaky tests from the fast_check_gdb CI job, and also one that makes it flag regressions in the stable tests. - Implemented change in Abe to build glibc with SystemTap probes enabled, but there's a kludge I still need to cleanup before submitting it for review. - Working on change to tcwg_gnu-build.sh to make it run failed tests again to see if they change to passing status. I have a working prototype. Now running further tests and cleaning up the code. -- Thiago

1 year, 2 months

Re: Seeking toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi

by Maxim Kuvyrkov

Hi Bryan, > On Feb 7, 2023, at 9:13 PM, Bryan Phillippe <bp(a)darkforest.org> wrote: > ... > -rwxr-xr-x 1 config root 2765178 Dec 9 2018 /lib/libuClibc-1.0.14.so > /root # strings /lib/libuClibc-1.0.14.so |grep -i linaro|head -n 1 > GCC: (OpenWrt/Linaro GCC 4.8-2014.04 r35193) 4.8.3 This indicates that it was built with an OpenWRT toolchain, and OpenWRT project maintainers used Linaro GCC 4.8 source release, instead of FSF GCC 4.8 source release. In the days of GCC 4.8 it was very common to use Linaro GCC source release instead of FSF ones for building compilers for 32-bit and 64-bit ARM. Try searching in OpenWRT archives for a copy of GCC 4.8-based toolchain. > /root # strings /lib/libuClibc-1.0.14.so |grep -i gcc-4.8|head -n 1 > /home/test/work/sudhan-qsdk/qsdk/build_dir/toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi/uClibc-ng-1.0.14 > /root # > > I only need to rebuild a single binary on this platform, and I don't have the source or the toolchain for the existing binaries. If I have to recreate a toolchain based on the versions only, it should be possible, but will be a good deal of work and effort. If you know where I can find this toolchain - or have any advice on how I can build my own compatible version - I would be very grateful. If you want to rebuild a single executable, then it may be easier to use a modern toolchain for arm-linux-gnueabihf [1] and build the static binary of your package (add "-static" to compiler flags). This was the binary will include all necessary bits of system libraries. This is a good approach if your package does not have dependencies outside of C library; otherwise you would need to find static versions of all other libraries. -- Maxim Kuvyrkov https://www.linaro.org > > Thank you so much! > > -- > -bp > >> On Feb 7, 2023, at 04:24, Maxim Kuvyrkov <maxim.kuvyrkov(a)linaro.org> wrote: >> >> [CC: linaro-toolchain@] >> >> Hi Bryan, >> >> I don't think that Linaro has ever released a toolchain with uClibc, but I may be wrong. Could you provide additional information about the target, rootfs and your setup? >> >> -- >> Maxim Kuvyrkov >> https://www.linaro.org >> >> >> >> >>> On Feb 7, 2023, at 10:31 AM, Bryan Phillippe <bp(a)darkforest.org> wrote: >>> >>> >>> Hello! I know this is a long shot, but I have a few devices with code that was built using this toolchain: toolchain-arm_cortex-a7_gcc-4.8-linaro_uClibc-1.0.14_eabi >>> >>> I'm trying to find a copy of that so I can rebuild 1 binary/package on the system without blowing everything up. Do you have any idea where I can find this toolchain? Thank you so much in advance! >>> >>> -- >>> -bp >>> >> >

1 year, 2 months

Clang C++ linkage problem

by Bartosz Golaszewski

Hey! I'm the author and maintainer of libgpiod. I'm currently getting ready to do a new major release. After giving some exposure to the release candidate, I noticed that when using clang, I can't link against the C++ bindings, while it works just fine in GCC. The tree in question is here: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/log/ You can trigger the linking program by trying to build the C++ tests with clang like that: CC=clang CXX=clang++ ./autogen.sh --enable-bindings-cxx --enable-tests && make -j16 You'll get the following error: /usr/bin/ld: tests-chip.o:(.data+0x0): undefined reference to `typeinfo for gpiod::chip_closed' /usr/bin/ld: tests-line-request.o:(.data+0x0): undefined reference to `typeinfo for gpiod::request_released' /usr/bin/ld: .libs/gpiod-cxx-test: hidden symbol `_ZTIN5gpiod11chip_closedE' isn't defined /usr/bin/ld: final link failed: bad value The typoinfo is missing for exception types that should be visible to users of the library. The culprit is here: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings/cxx… I added the GPIOD_CXX_BUILD macro in order to not re-export the visible symbols if any user of the library would include the gpiod.hpp header. When the library is being built, the symbols are visible, when someone includes the header, the symbols are hidden. If I make the symbols unconditionally visible here, clang starts to work but I have no idea why and would like to avoid re-exporting the symbols if I can. I'm using the following version: Ubuntu clang version 15.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Host is: x86_64 GNU/Linux It's not like gcc links fine but then fails to obtain typeid - I can catch exceptions coming out from libgpiod just fine in external apps linked using gcc and see their type. Any hints? Thanks Bart

1 year, 2 months

[ACTIVITY] Report for week #6

by Thiago Jung Bauermann

Hello, # [GNU-767] Support changing SVE vector length in remote debugging - Continued addressing review comments on v3 of the patches. Implemented some of the suggestions in my local branch, and also engaged in discussions. # [GNU-796] Stabilize GDB testsuite results in the CI - Fixed the problem in tcwg_gnu-build.sh noticed by Maxim where no_regression_p ignored regressions in the fast_check_gdb CI job. - Removed gdb.gdb/unittest.exp and gdb.server/unittest.exp from the fast_check_gdb stable tests list. The former only temporarily while its flakiness isn't fixed, and the latter because we don't run remote CI jobs. - Found out why gdb.base/break-probes.exp is unsupported in the fast_check_gdb CI job: we don't build glibc with SystemTap static probes. I have local changes to add them — and which do fix the GDB test — but I need to clean them up a bit before pushing them. -- Thiago

1 year, 2 months

[ACTIVITY] report week ending 10 Feb

by Peter Maydell

Progress: * UM-2 [QEMU upstream maintainership] - Code review. In particular: reviewed RTH's FEAT_RME series - Wrote and sent an RFC patchset proposing renaming of the badly misnamed '-singlestep' command line option (it actually does "put only one guest instruction in each JIT basic block") -- PMM

1 year, 2 months

[ACTIVITY] week ending Feb. 12 2023

by Alex Bennée

Project Stratos =============== - more prep work for Project Orko FEAT_RME, CCA Realms ([QEMU-466]) ================================= - sync up meeting with Huawei - see QEMU, FEAT_RME/CCA and next steps Message-Id: <87mt5ln2t6.fsf(a)linaro.org> QEMU Upstream Work ([UM-2]) =========================== - posted [RFC PATCH] tests/avocado: retire the Aarch64 TCG tests from boot_linux.py Message-Id: <20230203181632.2919715-1-alex.bennee(a)linaro.org> - continued working on [testing/next] with tuxrun tests - hacked up [PoC to use local QEMU in TuxRun] [UM-2] <https://linaro.atlassian.net/browse/UM-2> [testing/next] <https://github.com/stsquad/qemu/tree/testing/next> [PoC to use local QEMU in TuxRun] <https://gitlab.com/stsquad/tuxrun/-/commit/0f9711c18b7e723e1c50c8a8fd116b93…> Completed Reviews [3/3] ======================= [PATCH v3 0/9] virtio-gpu: Support Venus Vulkan driver Message-Id: <20220926142422.22325-1-antonio.caggiano(a)collabora.com> [PATCH] gdbstub: move update guest debug to accel ops Message-Id: <20221123121712.72817-1-mads(a)ynddal.dk> [PATCH v2 0/3] Add gdbstub support to HVF Message-Id: <20221116174749.65175-1-fcagnin(a)quarkslab.com> Current Review Queue ==================== TODO [PATCH 00/22] target/arm: Implement FEAT_RME Message-Id: <20230124000027.3565716-1-richard.henderson(a)linaro.org> ==================================================================================================================== TODO [RFC PATCH 00/16] Add stage-2 translation for SMMUv3 Message-Id: <20230205094411.793816-1-smostafa(a)google.com> ================================================================================================================== TODO [PATCH v2 0/2] fix for #285 Message-Id: <20230205163758.416992-1-cota(a)braap.org> ==================================================================================== -- Alex Bennée Virtualisation Tech Lead @ Linaro

1 year, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain February 2023