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
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
>>>
>>
>
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
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
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
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
[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
>
Hello,
# [GNU-767] Support changing SVE vector length in remote debugging
- The patches were already reviewed by 3 maintainers, so started addressing
their review comments and answering questions.
- Committed first two patches in the series, which were self-contained code
improvements.
--
Thiago
Project Stratos
===============
- posted [PATCH v2] backends/vhost-user: remove the ioeventfd check
Message-Id: <20230130124728.175610-1-alex.bennee(a)linaro.org>
- bunch of sync and planning for Project Orko
- see Project Orko requirements from TRS Message-Id:
<87sffmke2i.fsf(a)linaro.org>
- also debugging some TRS <-> QEMU interactions
- posted [RFC PATCH] target/arm: disable FEAT_SME if we turn off SVE
Message-Id: <20230203100551.2445547-1-alex.bennee(a)linaro.org>
[proposal for Unprivilaged VirtIO API]
<https://docs.google.com/document/d/18ijlX2Lguejyo3BV8Tri5Y_d1SmozocBIk2ajgq…>
QEMU Upstream Work ([UM-2])
===========================
- posted [PULL v2 00/36] Testing, docs, semihosting and plugin updates
Message-Id: <20230202160109.2061994-1-alex.bennee(a)linaro.org>
- posted [RFC PATCH] tests/avocado: retire the Aarch64 TCG tests from
boot_linux.py Message-Id:
<20230203181632.2919715-1-alex.bennee(a)linaro.org>
Other
=====
- Did some investigation into LKFT regressions
- posted Initial investigation of slowness kselftest job Message-Id:
<1ba91912e18492c7dafedc5fbd5aef817f109d53fdc95554870edf077a6e21dc(a)mu.id>
- posted Candidate patches for Debian's 7.2 release (and backports)
Message-Id: <87edr8kqqq.fsf(a)linaro.org>
Completed Reviews [4/4]
=======================
[PATCH v6 00/36] tcg: Support for Int128 with helpers
Message-Id: <20230130214844.1158612-1-richard.henderson(a)linaro.org>
[PATCH] vhost-user-gpio: Configure vhost_dev when connecting
Message-Id: <20230130140320.77999-1-akihiko.odaki(a)daynix.com>
[PATCH] configure: Bump minimum Clang version to 10.0
Message-Id: <20230131180239.1582302-1-thuth(a)redhat.com>
[PATCH v3 0/9] virtio-gpu: Support Venus Vulkan driver
Message-Id: <20220926142422.22325-1-antonio.caggiano(a)collabora.com>
Current Review Queue
====================
TODO [PATCH 0/4] Fix deadlock when dying because of a signal
Message-Id: <20230201004609.3005029-1-iii(a)linux.ibm.com>
====================================================================================================================
TODO [RFC PATCH v1 0/8] Look Ma! We made a XenStore
Message-Id: <20230201144358.1744876-1-dwmw2(a)infradead.org>
=============================================================================================================
TODO [QEMU][PATCH v5 00/10] Introduce xenpvh machine for arm architecture
Message-Id: <20230131225149.14764-1-vikram.garhwal(a)amd.com>
====================================================================================================================================
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
Progress:
* UM-2 [QEMU upstream maintainership]
- usual upstream maintenance tasks
- the CI/tests have got rather flaky of late: trying to
find out why...
* QEMU-471 [QEMU ARM v9.0 Baseline CPU for TCG]
- FEAT_FGT: is now upstream
-- PMM
