Re: [Linaro-TCWG-CI] FAIL: 6 regressions after basepoints/gcc-14-3441-ga1558e9ad85 tree-optimization/111115 - SLP of masked stores
I just tested with 470da3b27e6dbeb3286b09dcb1c1b810ac75b276 and the issues still happens. I have opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56 On 24/08/23 16:12, Maxim Kuvyrkov wrote: > Hi Richard, > > Your patch below ICEs on aarch64-linux-gnu. Should reproduce easily on > native or cross aarch64-linux-gnu build. > > Let me know if you need any assistance in reproducing this. > > Thanks, > > -- > Maxim Kuvyrkov > https://www.linaro.org > >> On Aug 24, 2023, at 22:03, ci_not...@linaro.org wrote: >> >> Dear contributor, our automatic CI has detected problems related to your >> patch. >> Please find below some details about it. If you have any questions, please >> follow up on linaro-toolchain@lists.linaro.org mailing list. >> >> In CI config tcwg_gcc_check/master-aarch64 after: >> >> | commit a1558e9ad856938f165f838733955b331ebbec09 >> | Author: Richard Biener >> | Date: Wed Aug 23 14:28:26 2023 +0200 >> | >> | tree-optimization/15 - SLP of masked stores >> | >> | The following adds the capability to do SLP on .MASK_STORE, I do not >> | plan to add interleaving support. >> | >> | PR tree-optimization/15 >> | ... 21 lines of the commit log omitted. >> >> FAIL: 6 regressions >> >> regressions.sum: >> === gcc tests === >> >> Running gcc:gcc.target/aarch64/sve/aarch64-sve.exp ... >> FAIL: gcc.target/aarch64/sve/mask_struct_store_4.c (internal compiler error: >> in get_group_load_store_type, at tree-vect-stmts.cc:2121) >> FAIL: gcc.target/aarch64/sve/mask_struct_store_4.c (test for excess errors) >> UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not >> \\tst2b\\t.z[0-9] >> UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not >> \\tst2d\\t.z[0-9] >> UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not >> \\tst2h\\t.z[0-9] >> UNRESOLVED: gcc.target/aarch64/sve/mask_struct_store_4.c scan-assembler-not >> \\tst2w\\t.z[0-9] >> >> ... and 1 more entries >> >> >> >> -8<--8<--8<-- >> The information below can be used to reproduce a debug environment: >> >> Current build : >> https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/857/artifact/artifacts >> Reference build : >> https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/856/artifact/artifacts >> >> Reproduce last good and first bad builds: >> https://git.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/a1558e9ad856938f165f838733955b331ebbec09/reproduction_instructions.txt >> >> Full commit : >> https://github.com/gcc-mirror/gcc/commit/a1558e9ad856938f165f838733955b331ebbec09 >> >> Latest bug report status : https://linaro.atlassian.net/browse/GNU-893 >> >> List of configurations that regressed due to this commit : >> * tcwg_gcc_check >> ** master-aarch64 >> *** FAIL: 6 regressions >> *** https://ci.linaro.org/job/tcwg_gcc_check--master-aarch64-build/857/ > > ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] FAIL: 1 regressions after gcc commit
Hi Andrew, Your patch caused a regression [1] on aarch64-linux-gnu. Would you please investigate? I did a quick analysis and it seems that the expected 18 for aarch64 is now 17: $ grep "Jumps threaded" a-ssa-dom-thread-7.c.197t.thread2 Jumps threaded: 17 Let me know if you need any assistance in reproducing these. Thanks! [1] https://ci.linaro.org/job/tcwg_gnu_native_check_gcc--master-aarch64-build/567/artifact/artifacts/notify/mail-body.txt/*view*/ ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] FAIL: 2 regressions after gcc commit 27de9aa152141e7f3ee66372647d0f2cd94c4b90
Hi Richard, Your patch caused a regression [1] on aarch64-linux-gnu. Would you please investigate? I did a quick analysis and it seems that for test_copy_lane_f32, test_copy_lane_s32, test_copy_lane_u32, gcc is now generating zip1 instead of a ins; which does not seem fully correct. Let me know if you need any assistance in reproducing these. Thanks! [1] https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/912/artifact/artifacts/notify/mail-body.txt/*view*/ ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
[Linaro-TCWG-CI] FAIL: regressions after gcc commit 0c78240fd7d519fc27ca822f66a92f85edf43f70
Hi Jan, Your patch caused a regression [1] on aarch64-linux-gnu. Would you please investigate? I am having some trouble to reproduce it outside our CI environment, but it has been hitting this issues consistently and it does seems related to your patch. Let me know if you need any assistance in reproducing these. Thanks! [1] https://ci.linaro.org/job/tcwg_bootstrap_build--master-aarch64-bootstrap_profiled-build/194/artifact/artifacts/notify/mail-body.txt/*view*/ ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc-2.38.9000-496-gdf11c05be9: FAIL: 1 regressions on arm
On 18/01/24 10:23, Joseph Myers wrote: > On Thu, 18 Jan 2024, ci_not...@linaro.org wrote: > >> In master-arm after: >> >> | commit glibc-2.38.9000-496-gdf11c05be9 >> | Author: Joseph Myers >> | Date: Wed Jan 17 15:38:54 2024 + >> | >> | Update syscall lists for Linux 6.7 >> | >> | Linux 6.7 adds the futex_requeue, futex_wait and futex_wake syscalls, >> | and enables map_shadow_stack for architectures previously missing it. >> | Update syscall-names.list and regenerate the arch-syscall.h headers >> | with build-many-glibcs.py update-syscalls. >> | >> | ... 1 lines of the commit log omitted. >> >> FAIL: 1 regressions >> >> regressions.sum: >> === glibc tests === >> >> Running glibc:misc ... >> FAIL: misc/tst-glibcsyscalls > > You appear to be testing with some other kernel version with additional > syscalls that are not in the actual 6.7 release. > Yes, we test Linus master branch instead of a specific release. This is not a really a glibc regression, sorry about the noise. ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc patch #85585: FAIL: 1 regressions on arm
On 15/02/24 08:47, H.J. Lu wrote: > On Thu, Feb 15, 2024 at 12:01 AM Maxim Kuvyrkov > wrote: >> >>> On Feb 15, 2024, at 03:54, H.J. Lu wrote: >>> >>> FAIL: elf/tst-gnu2-tls2 >>> >>> indicates that your _dl_tlsdesc_dynamic may not preserve all caller-saved >>> registers. Please find out how the test fails. >> >> Hi H.J., >> >> See below. >> >> ... >>> FAIL: 1 regressions >>> >>> regressions.sum: >>>=== glibc tests === >>> >>> Running glibc:elf ... >>> FAIL: elf/tst-gnu2-tls2 >>> >>> >>> You can find the failure logs in *.log.1.xz files in >>> - >>> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/ >> >> tests.log.1.xz contains output of failed tests -- >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/tests.log.1.xz >> === >> FAIL: elf/tst-gnu2-tls2 >> original exit status 1 >> open tst-gnu2-tls2mod0.so >> open tst-gnu2-tls2mod1.so >> open tst-gnu2-tls2mod2.so >> close tst-gnu2-tls2mod0.so >> close tst-gnu2-tls2mod1.so >> open tst-gnu2-tls2mod0.so >> open tst-gnu2-tls2mod1.so >> Didn't expect signal from child: got `Segmentation fault' >> === >> >> Let me know if you need any help investigating this. >> > > I don't have access to aarch64 machine which can build glibc. > Please configure glibc with --enable-hardcoded-path-in-tests > and run elf/tst-gnu2-tls2 under GDB to find out what is going > on. > I will check this out H.J. ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc patch #85585: FAIL: 1 regressions on arm
On 15/02/24 09:13, H.J. Lu wrote: > On Thu, Feb 15, 2024 at 4:12 AM H.J. Lu wrote: >> >> On Thu, Feb 15, 2024 at 3:49 AM Adhemerval Zanella Netto >> wrote: >>> >>> >>> >>> On 15/02/24 08:47, H.J. Lu wrote: >>>> On Thu, Feb 15, 2024 at 12:01 AM Maxim Kuvyrkov >>>> wrote: >>>>> >>>>>> On Feb 15, 2024, at 03:54, H.J. Lu wrote: >>>>>> >>>>>> FAIL: elf/tst-gnu2-tls2 >>>>>> >>>>>> indicates that your _dl_tlsdesc_dynamic may not preserve all caller-saved >>>>>> registers. Please find out how the test fails. >>>>> >>>>> Hi H.J., >>>>> >>>>> See below. >>>>> >>>>> ... >>>>>> FAIL: 1 regressions >>>>>> >>>>>> regressions.sum: >>>>>>=== glibc tests === >>>>>> >>>>>> Running glibc:elf ... >>>>>> FAIL: elf/tst-gnu2-tls2 >>>>>> >>>>>> >>>>>> You can find the failure logs in *.log.1.xz files in >>>>>> - >>>>>> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/ >>>>> >>>>> tests.log.1.xz contains output of failed tests -- >>>>> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/1460/artifact/artifacts/artifacts.precommit/00-sumfiles/tests.log.1.xz >>>>> === >>>>> FAIL: elf/tst-gnu2-tls2 >>>>> original exit status 1 >>>>> open tst-gnu2-tls2mod0.so >>>>> open tst-gnu2-tls2mod1.so >>>>> open tst-gnu2-tls2mod2.so >>>>> close tst-gnu2-tls2mod0.so >>>>> close tst-gnu2-tls2mod1.so >>>>> open tst-gnu2-tls2mod0.so >>>>> open tst-gnu2-tls2mod1.so >>>>> Didn't expect signal from child: got `Segmentation fault' >>>>> === >>>>> >>>>> Let me know if you need any help investigating this. >>>>> >>>> >>>> I don't have access to aarch64 machine which can build glibc. >>>> Please configure glibc with --enable-hardcoded-path-in-tests >>>> and run elf/tst-gnu2-tls2 under GDB to find out what is going >>>> on. >>>> >>> >>> I will check this out H.J. >> >> Does your _dl_tlsdesc_dynamic save ALL caller-saved registers, >> except for the return value register? I saw >> >> stp x5, x6, [sp, #16*1] >> stp x7, x8, [sp, #16*2] >> stp x9, x10, [sp, #16*3] >> stp x11, x12, [sp, #16*4] >> stp x13, x14, [sp, #16*5] >> stp x15, x16, [sp, #16*6] >> stp x17, x18, [sp, #16*7] >> >> Do you need to save x1 to x4? >> >> -- >> H.J. > > If your processor is also impacted, please add it to > > https://sourceware.org/bugzilla/show_bug.cgi?id=31372 > Hi H.J. The issues is not really on aarch64, but rather arm 32 bits. And it is seems to be a real one on arm _dl_tlsdesc_dynamic implementation, that fail to save/restore r12 that is used by gcc as a scratch register. I have added 3 more fixes on top on your patches [1]. First one is a small fix for the -mtls-dialect=gnu2 configure test that fail when -mtp=soft is used (used by default arm-linux-gnueabihf cross compiler produced by build-many-glibcs.py). Second is the arm fix for BZ 31372 regression. However, I am not sure if this suffice, since similar to others ABIs, arm also support vector extensions (VFP, VFP3, and neon). I think we will eventually need to do something similar to what you did for x86 and provided either multiple _dl_tlsdesc_dynamic or handle the vector register save/restore using hwcap feature check (or we can also eventually just remove the slow patch and get over this whole save/restore vector extensions). This is not an issue now on arm32 because gnu2 is not default and I don't think gcc will flip the switch in near future. The last patch enables TLS descriptor tests on aarch64 as well, since it uses a different name of gnu2. I think RISC-V will use the same naming as aarch64, so it would make easier to enable such tests on this abi as well. [1] https://github.com/zatrazz/glibc/commits/azanella/tls-descriptor-fixes-arm/ ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc-2.39.9000-340-g176671f604: FAIL: 1 regressions on aarch64
On 18/06/24 13:37, Florian Weimer wrote: > * ci notify: > >> In glibc_check master-aarch64 after: >> >> | commit glibc-2.39.9000-340-g176671f604 >> | Author: Carlos Llamas >> | Date: Tue Jun 18 10:56:34 2024 +0200 >> | >> | linux: add definitions for hugetlb page size encodings >> | >> | A desired hugetlb page size can be encoded in the flags parameter of >> | system calls such as mmap() and shmget(). The Linux UAPI headers have >> | included explicit definitions for these encodings since v4.14. >> | >> | This patch adds these definitions that are used along with >> MAP_HUGETLB >> | ... 14 lines of the commit log omitted. >> >> FAIL: 1 regressions >> >> regressions.sum: >> === glibc tests === >> >> Running glibc:misc ... >> FAIL: misc/tst-mman-consts > > This must be the error I saw elsewhere: > > | First source: > | #define _GNU_SOURCE 1 > | #include > | > | > | Second source: > | #define _GNU_SOURCE 1 > | #include > | > | > | Only in first source: MAP_ABOVE4G > | Different values for MAP_HUGE_16GB: 2281701376 != -2013265920 > > The reason is that the kernel changed the definition of MAP_HUGE_16GB. > Older UAPI headers use an undefined expression which is treated by > compilers as a signed int, hence t he discrepancy. > > This was fixed on the kernel side in this commit: > > commit 710bb68c2e3a24512e2d2bae470960d7488e97b1 > Author: Matthias Goergens > Date: Mon Sep 5 11:19:04 2022 +0800 > > hugetlb_encode.h: fix undefined behaviour (34 << 26) > > Left-shifting past the size of your datatype is undefined behaviour in C. > The literal 34 gets the type `int`, and that one is not big enough to be > left shifted by 26 bits. > > An `unsigned` is long enough (on any machine that has at least 32 bits for > their ints.) > > For uniformity, we mark all the literals as unsigned. But it's only > really needed for HUGETLB_FLAG_ENCODE_16GB. > > Thanks to Randy Dunlap for an initial review and suggestion. > > Link: > https://lkml.kernel.org/r/20220905031904.150925-1-matthias.goerg...@gmail.com > Signed-off-by: Matthias Goergens > Acked-by: Randy Dunlap > Cc: Mike Kravetz > Cc: Muchun Song > Signed-off-by: Andrew Morton > > Not sure what to do about this on the glibc side. Can we waive this in > the CI, or should try to fix up the glibc test? At least for Linaro CI it won't trigger any additional issues, the misc/tst-mman-consts will be marked as flaky tests on additional tests. I think we can waive this for now. ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] 4 patches in glibc: FAIL: 1 regressions on arm
On 04/09/24 03:58, Florian Weimer wrote: > * ci notify: > >> Dear contributor, our automatic CI has detected problems related to your >> patch(es). Please find some details below. If you have any questions, >> please follow up on linaro-toolchain@lists.linaro.org mailing list, Libera's >> #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on >> the usual project channel. >> >> We understand that it might be difficult to find the necessary logs or >> reproduce the issue locally. If you can't get what you need from our CI >> within minutes, let us know and we will be happy to help. >> >> In glibc_check master-arm after: >> >> | 4 patches in glibc >> | Patchwork URL: https://patchwork.sourceware.org/patch/96984 >> | 11d52d986b elf: Reorder audit events in dlcose to match _dl_fini (bug >> 32066) >> | 7b2cd1e545 elf: Call la_objclose for proxy link maps in _dl_fini (bug >> 32065) >> | 0f79eb4a6f elf: Signal la_objopen for the proxy link map in dlmopen (bug >> 31985) >> | f26a9b6323 elf: Always write audit log to elf/tst-audit23.out >> | ... applied on top of baseline commit: >> | 96d0bf98ca Add support/ code for checking file contents >> >> FAIL: 1 regressions >> >> regressions.sum: >> === glibc tests === >> >> Running glibc:elf ... >> FAIL: elf/tst-audit23 > > Adhemerval, does elf/tst-audit23.out now show more details? > Hi Florian, You can find the detail inside the job folder [1] (it is not straightforward, but it is there): FAIL: elf/tst-audit23 original exit status 1 info: *** audit log start *** 1 la_objopen: f7f06d38 mainapp f7ec 0 2 la_objopen: f7f06860 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/ld-linux-armhf.so.3 f7ed9000 0 3 la_activity: 1 f7f06d38 4 la_objopen: f7f00878 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libgcc_s.so.1 f7c4 0 5 la_objopen: f7f00c38 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libc.so.6 f7b1 0 6 la_activity: 0 f7f06d38 7 la_activity: 1 f7f06d38 8 la_objopen: 234c4a0 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/tst-audit23mod.so f7af 0 9 la_activity: 0 f7f06d38 10 la_activity: 1 234c8e0 11 la_objopen: 234c8e0 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libc.so.6 f79c 2 12 la_objopen: 234ccb8 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/ld-linux-armhf.so.3 f7ed9000 2 13 la_activity: 0 234c8e0 14 la_activity: 2 234c8e0 15 la_objclose: 234c8e0 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libc.so.6 f79c 2 16 la_objclose: 234ccb8 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/ld-linux-armhf.so.3 f7ed9000 2 17 la_activity: 0 234c8e0 18 la_activity: 2 f7f06d38 19 la_objclose: f7f06d38 mainapp f7ec 0 20 la_objclose: f7f00878 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libgcc_s.so.1 f7c4 0 21 la_objclose: 234c4a0 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/tst-audit23mod.so f7af 0 22 la_objclose: f7f00c38 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libc.so.6 f7b1 0 23 la_objclose: f7f06860 /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/ld-linux-armhf.so.3 f7ed9000 0 24 la_activity: 0 f7f06d38 info: *** audit log end *** error: tst-audit23.c:201: (line 12) non expected la_objopen: /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/elf/ld-linux-armhf.so.3 f7ed9000 2 error: 1 test failures [1] https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/2438/artifact/artifacts/artifacts.precommit/00-sumfiles/tests.log.0.xz ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] 4 patches in glibc: FAIL: 1 regressions on arm
On 04/09/24 13:52, Florian Weimer wrote: > * Adhemerval Zanella Netto: > >> 4 la_objopen: f7f00878 >> /home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/glibc-glibc.git~master/libgcc_s.so.1 >> f7c4 0 > > Thanks, libgcc_s is unexpected here and I'll try to figure out where > this is coming from. It comes from 1d5024f4f052c12e404d42d3b5bfe9c3e9fd27c4, which makes all the tests require libgcc_s.so on armhf because of how its implemented on the ABI. We had to recently fix a similar issue (97290559c3b497fb9012c3f6248cb30afb26da7c). ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: Clang C++ linkage problem
On 13/02/23 12:49, Bartosz Golaszewski wrote:
> 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/gpiod.hpp#n26
>
> 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.
But the typeid of the symbol, for instance gpiod, will still be provided
by shared library if I understood correctly:
libgpiod-llvm$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null| grep
-w _ZTIN5gpiod11chip_closedE
*UND* .hidden
_ZTIN5gpiod11chip_closedE
libgpiod-llvm$ objdump -t bindings/cxx/.libs/libgpiodcxx.so 2>/dev/null| grep
_ZTIN5gpiod11chip_closedE
00024b50 g O .data.rel.ro 0018
_ZTIN5gpiod11chip_closedE
However, it seems that GCC is not applying the hidden attribute on the
typeid class:
libgpiod-gcc$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null| grep -w
_ZTIN5gpiod11chip_closedE
wO .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE
0008 .hidden DW.ref._ZTIN5gpiod11chip_closedE
*UND* _ZTIN5gpiod11chip_closedE
When it creates create the vague linking weak symbol
.data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE.
I am not sure why GCC is being permissive here, in fact IMHO this is
gcc issue. If I add the visibility explicitly using pragmas:
diff --git a/bindings/cxx/gpiodcxx/exception.hpp
b/bindings/cxx/gpiodcxx/exception.hpp
index 98b7bc4..24ae698 100644
--- a/bindings/cxx/gpiodcxx/exception.hpp
+++ b/bindings/cxx/gpiodcxx/exception.hpp
@@ -17,6 +17,8 @@
namespace gpiod {
+#pragma GCC visibility push(hidden)
+
/**
* @ingroup gpiod_cxx
* @{
@@ -25,7 +27,7 @@ namespace gpiod {
/**
* @brief Exception thrown when an already closed chip is used.
*/
-class GPIOD_CXX_API chip_closed : public ::std::logic_error
+class /*GPIOD_CXX_API*/ chip_closed : public ::std::logic_error
{
public:
@@ -64,6 +66,8 @@ public:
virtual ~chip_closed();
};
+#pragma GCC visibility pop
+
/**
* @brief Exception thrown when an already released line request is used.
*/
I get an explicit linking error:
/usr/bin/ld:
tests-chip.o:(.data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE[DW.ref._ZTIN5gpiod11chip_closedE]+0x0):
undefined reference to `typeinfo for gpiod::chip_closed'
Which is what I expect. So I suggest you to avoid adding the hidden
visibility on tests because since there are not linking static, they
should follow the default rules of ABI and hidden in this case does
not really make much sense.
>
> 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?
___
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org
To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: Clang C++ linkage problem
On 13/02/23 16:22, Bartosz Golaszewski wrote:
> On Mon, 13 Feb 2023 at 19:49, Adhemerval Zanella Netto
> wrote:
>>
>>
>>
>> On 13/02/23 12:49, Bartosz Golaszewski wrote:
>>> 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/gpiod.hpp#n26
>>>
>>> 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.
>>
>> But the typeid of the symbol, for instance gpiod, will still be provided
>> by shared library if I understood correctly:
>>
>> libgpiod-llvm$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null|
>> grep -w _ZTIN5gpiod11chip_closedE
>> *UND* .hidden
>> _ZTIN5gpiod11chip_closedE
>> libgpiod-llvm$ objdump -t bindings/cxx/.libs/libgpiodcxx.so 2>/dev/null|
>> grep _ZTIN5gpiod11chip_closedE
>> 00024b50 g O .data.rel.ro 0018
>> _ZTIN5gpiod11chip_closedE
>>
>> However, it seems that GCC is not applying the hidden attribute on the
>> typeid class:
>>
>> libgpiod-gcc$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null| grep
>> -w _ZTIN5gpiod11chip_closedE
>> wO .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE
>>0008 .hidden DW.ref._ZTIN5gpiod11chip_closedE
>> *UND* _ZTIN5gpiod11chip_closedE
>>
>> When it creates create the vague linking weak symbol
>> .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE.
>>
>> I am not sure why GCC is being permissive here, in fact IMHO this is
>> gcc issue. If I add the visibility explicitly using pragmas:
>>
>> diff --git a/bindings/cxx/gpiodcxx/exception.hpp
>> b/bindings/cxx/gpiodcxx/exception.hpp
>> index 98b7bc4..24ae698 100644
>> --- a/bindings/cxx/gpiodcxx/exception.hpp
>> +++ b/bindings/cxx/gpiodcxx/exception.hpp
>> @@ -17,6 +17,8 @@
>>
>> namespace gpiod {
>>
>> +#pragma GCC visibility push(hidden)
>> +
>> /**
>> * @ingroup gpiod_cxx
>> * @{
>> @@ -25,7 +27,7 @@ namespace gpiod {
>> /**
>> * @brief Exception thrown when an already closed chip is used.
>> */
>> -class GPIOD_CXX_API chip_closed : public ::std::logic_error
>> +class /*GPIOD_CXX_API*/ chip_closed : public ::std::logic_error
>> {
>> public:
>>
>> @@ -64,6 +66,8 @@ public:
>> virtual ~chip_closed();
>> };
>>
>> +#pragma GCC visibility pop
>> +
>> /**
>> * @brief Exception thrown when an already released line request is used.
>> */
>>
>> I get an explicit linking error:
>>
>> /usr/bin/ld:
>> tests-chip.o:(.data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE[DW.ref._ZTIN5gpiod11chip_closedE]+0x0):
>> undefined reference to `typeinfo for gpiod::chip_closed'
>>
>> Which is what I expect. So I suggest you to avoid adding the hidden
>> visibility on tests because since there are not linking static, they
>> should follow the default rules o
Re: Clang C++ linkage problem
On 13/02/23 17:05, Bartosz Golaszewski wrote:
> On Mon, 13 Feb 2023 at 20:53, Adhemerval Zanella Netto
> wrote:
>>
>>
>>
>> On 13/02/23 16:22, Bartosz Golaszewski wrote:
>>> On Mon, 13 Feb 2023 at 19:49, Adhemerval Zanella Netto
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 13/02/23 12:49, Bartosz Golaszewski wrote:
>>>>> 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/gpiod.hpp#n26
>>>>>
>>>>> 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.
>>>>
>>>> But the typeid of the symbol, for instance gpiod, will still be provided
>>>> by shared library if I understood correctly:
>>>>
>>>> libgpiod-llvm$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null|
>>>> grep -w _ZTIN5gpiod11chip_closedE
>>>> *UND* .hidden
>>>> _ZTIN5gpiod11chip_closedE
>>>> libgpiod-llvm$ objdump -t bindings/cxx/.libs/libgpiodcxx.so 2>/dev/null|
>>>> grep _ZTIN5gpiod11chip_closedE
>>>> 00024b50 g O .data.rel.ro 0018
>>>> _ZTIN5gpiod11chip_closedE
>>>>
>>>> However, it seems that GCC is not applying the hidden attribute on the
>>>> typeid class:
>>>>
>>>> libgpiod-gcc$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null|
>>>> grep -w _ZTIN5gpiod11chip_closedE
>>>> wO .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE
>>>> 0008 .hidden DW.ref._ZTIN5gpiod11chip_closedE
>>>> *UND* _ZTIN5gpiod11chip_closedE
>>>>
>>>> When it creates create the vague linking weak symbol
>>>> .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE.
>>>>
>>>> I am not sure why GCC is being permissive here, in fact IMHO this is
>>>> gcc issue. If I add the visibility explicitly using pragmas:
>>>>
>>>> diff --git a/bindings/cxx/gpiodcxx/exception.hpp
>>>> b/bindings/cxx/gpiodcxx/exception.hpp
>>>> index 98b7bc4..24ae698 100644
>>>> --- a/bindings/cxx/gpiodcxx/exception.hpp
>>>> +++ b/bindings/cxx/gpiodcxx/exception.hpp
>>>> @@ -17,6 +17,8 @@
>>>>
>>>> namespace gpiod {
>>>>
>>>> +#pragma GCC visibility push(hidden)
>>>> +
>>>> /**
>>>> * @ingroup gpiod_cxx
>>>> * @{
>>>> @@ -25,7 +27,7 @@ namespace gpiod {
>>>> /**
>>>> * @brief Exception thrown when an already closed chip is used.
>>>> */
>>>> -class GPIOD_CXX_API chip_closed : publi
Re: Clang C++ linkage problem
On 13/02/23 17:25, Bartosz Golaszewski wrote: > On Mon, 13 Feb 2023 at 21:17, Adhemerval Zanella Netto > wrote: >> >> >> >> On 13/02/23 17:05, Bartosz Golaszewski wrote: >>> On Mon, 13 Feb 2023 at 20:53, Adhemerval Zanella Netto >>> wrote: >>>> >>>> >>>> >>>> On 13/02/23 16:22, Bartosz Golaszewski wrote: >>>>> On Mon, 13 Feb 2023 at 19:49, Adhemerval Zanella Netto >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 13/02/23 12:49, Bartosz Golaszewski wrote: >>>>>>> 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/gpiod.hpp#n26 >>>>>>> >>>>>>> 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. >>>>>> >>>>>> But the typeid of the symbol, for instance gpiod, will still be provided >>>>>> by shared library if I understood correctly: >>>>>> >>>>>> libgpiod-llvm$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null| >>>>>> grep -w _ZTIN5gpiod11chip_closedE >>>>>> *UND* .hidden >>>>>> _ZTIN5gpiod11chip_closedE >>>>>> libgpiod-llvm$ objdump -t bindings/cxx/.libs/libgpiodcxx.so 2>/dev/null| >>>>>> grep _ZTIN5gpiod11chip_closedE >>>>>> 00024b50 g O .data.rel.ro 0018 >>>>>> _ZTIN5gpiod11chip_closedE >>>>>> >>>>>> However, it seems that GCC is not applying the hidden attribute on the >>>>>> typeid class: >>>>>> >>>>>> libgpiod-gcc$ objdump -t ./bindings/cxx/tests/tests-chip.o 2>/dev/null| >>>>>> grep -w _ZTIN5gpiod11chip_closedE >>>>>> wO >>>>>> .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE 0008 >>>>>> .hidden DW.ref._ZTIN5gpiod11chip_closedE >>>>>> *UND* >>>>>> _ZTIN5gpiod11chip_closedE >>>>>> >>>>>> When it creates create the vague linking weak symbol >>>>>> .data.rel.local.DW.ref._ZTIN5gpiod11chip_closedE. >>>>>> >>>>>> I am not sure why GCC is being permissive here, in fact IMHO this is >>>>>> gcc issue. If I add the visibility explicitly using pragma
Re: Clang C++ linkage problem
On 13/02/23 19:04, Bartosz Golaszewski wrote: > On Mon, 13 Feb 2023 at 21:41, Adhemerval Zanella Netto > wrote: >> >> >> >> On 13/02/23 17:25, Bartosz Golaszewski wrote: >>> On Mon, 13 Feb 2023 at 21:17, Adhemerval Zanella Netto >>> wrote: >>>> >>>> >>>> >>>> On 13/02/23 17:05, Bartosz Golaszewski wrote: >>>>> On Mon, 13 Feb 2023 at 20:53, Adhemerval Zanella Netto >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 13/02/23 16:22, Bartosz Golaszewski wrote: >>>>>>> On Mon, 13 Feb 2023 at 19:49, Adhemerval Zanella Netto >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 13/02/23 12:49, Bartosz Golaszewski wrote: >>>>>>>>> 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/gpiod.hpp#n26 >>>>>>>>> >>>>>>>>> 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. >>>>>>>> >>>>>>>> But the typeid of the symbol, for instance gpiod, will still be >>>>>>>> provided >>>>>>>> by shared library if I understood correctly: >>>>>>>> >>>>>>>> libgpiod-llvm$ objdump -t ./bindings/cxx/tests/tests-chip.o >>>>>>>> 2>/dev/null| grep -w _ZTIN5gpiod11chip_closedE >>>>>>>> *UND* .hidden >>>>>>>> _ZTIN5gpiod11chip_closedE >>>>>>>> libgpiod-llvm$ objdump -t bindings/cxx/.libs/libgpiodcxx.so >>>>>>>> 2>/dev/null| grep _ZTIN5gpiod11chip_closedE >>>>>>>> 00024b50 g O .data.rel.ro 0018 >>>>>>>> _ZTIN5gpiod11chip_closedE >>>>>>>> >>>>>>>> However, it seems that GCC is not applying the hidden attribute on the >>>>>>>> typeid class: >>>>>>>> >>>>>>>> libgpiod-gcc$ objdump -t ./bindings/cxx/tests/tests-chip.o >>>>&
Re: Clang C++ linkage problem
On 14/02/23 10:41, Bartosz Golaszewski wrote: > On Tue, 14 Feb 2023 at 14:33, Bartosz Golaszewski > wrote: >> >> On Tue, 14 Feb 2023 at 11:52, Adhemerval Zanella Netto >> wrote: >>> >>> >>> >>> On 13/02/23 19:04, Bartosz Golaszewski wrote: >>>> On Mon, 13 Feb 2023 at 21:41, Adhemerval Zanella Netto >>>> wrote: >>>>> >>>>> >>>>> >>>>> On 13/02/23 17:25, Bartosz Golaszewski wrote: >>>>>> On Mon, 13 Feb 2023 at 21:17, Adhemerval Zanella Netto >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 13/02/23 17:05, Bartosz Golaszewski wrote: >>>>>>>> On Mon, 13 Feb 2023 at 20:53, Adhemerval Zanella Netto >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 13/02/23 16:22, Bartosz Golaszewski wrote: >>>>>>>>>> On Mon, 13 Feb 2023 at 19:49, Adhemerval Zanella Netto >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 13/02/23 12:49, Bartosz Golaszewski wrote: >>>>>>>>>>>> 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/gpiod.hpp#n26 >>>>>>>>>>>> >>>>>>>>>>>> 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, >>>>>>>
Re: Need emit_expr to write right shifted value.
On 22/06/23 10:18, zac.wal...@linaro.org wrote: > Hi, > > In binutils I need to write an offset between two symbols shifted right by 2 > bits. This offset is written to the xdata section. My > code currently looks like this: > > exp.X_op = O_subtract; > exp.X_add_symbol = symbol1; > exp.X_op_symbol = symbol2; >emit_expr (&exp, 2); > > This works fine but obviously the result value is not shifted. Anyone have a > good option is to shift the output of emit_expr at > write time? > > I cannot use resolve_expression because the symbols do not have correct > addresses at the time this code executes. The 'struct expressionS' has the additional 'X_md' which is used by some targets to add extra rules for the expression. I am not very knowledge on this code, but I would expect that ld has a callback to handle the expressions prior the written. ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc patch #110503: 90 regressions on arm
Hi Stefan, I will take a look on this, but it might an docker or libseccomp update on the machine that has misconfigured some syscalls filtering. On 16/04/25 10:12, Stefan Liebler wrote: > Hi, > > I've looked into tests.log.1.xz and there are plenty of "Operation not > permitted" errors. I don't think that this has something to do with my > patch? Can you please check on your side, if there was a change/issue on > the build system? > > Bye, > Stefan > > On 4/16/25 13:32, ci_not...@linaro.org wrote: >> Dear contributor, >> >> Our automatic CI has detected problems related to your patch(es). Please >> find some details below. >> >> In glibc_check master-arm, after: >> | glibc patch https://patchwork.sourceware.org/patch/110503 >> | Author: Stefan Liebler >> | Date: Tue Apr 15 16:52:17 2025 +0200 >> | >> | [PATCH] S390: Add new s390 platform z17. >> | >> | The glibc-hwcaps subdirectories are extended by "z17". Libraries >> are loaded if >> | the z17 facility bits are active: >> | - Miscellaneous-instruction-extensions facility 4 >> | ... 35 lines of the commit log omitted. >> | ... applied on top of baseline commit: >> | ceeffd970c5 aarch64: Add back non-temporal load/stores from oryon-1's >> memset >> >> Produces 90 regressions: >> | >> | regressions.sum: >> | Running glibc:debug ... >> | FAIL: debug/tst-fortify-syslog >> | Running glibc:dirent ... >> | FAIL: dirent/tst-readdir-long >> | FAIL: dirent/tst-readdir-zero-inode >> | ... and 99 more >> >> Used configuration : >> *CI config* tcwg_glibc_check master-arm >> *configure and test flags:* none, autodetected on >> armv8l-unknown-linux-gnueabihf >> >> If you have any questions regarding this report, please ask on >> linaro-toolchain@lists.linaro.org mailing list. >> >> -8<--8<--8<-- >> >> The information below contains the details of the failures, and the ways to >> reproduce a debug environment: >> >> You can find the failure logs in *.log.1.xz files in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artifact/artifacts/artifacts.precommit/00-sumfiles/ >> The full lists of regressions and improvements as well as configure and make >> commands are in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artifact/artifacts/artifacts.precommit/notify/ >> The list of [ignored] baseline and flaky failures are in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail >> >> Current build : >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3528/artifact/artifacts >> Reference build : >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/2681/artifact/artifacts >> >> Warning: we do not enable maintainer-mode nor automatically update >> generated files, which may lead to failures if the patch modifies the >> master files. > > ___ > linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org > To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
Re: [Linaro-TCWG-CI] glibc patch #111247: 90 regressions on arm
Hi Stefan, We are seeing some issues on our side that it indicates some buildbot misconfiguration. I think you can ignore this for now, sorry for the noise. On 02/05/25 11:19, Stefan Liebler wrote: > Hi, > > For this V2-patch, I got the same "Operation not permitted" errors as > for the V1 one: > https://lists.linaro.org/archives/list/linaro-toolchain@lists.linaro.org/thread/2EHTRTCZHLDJZXZ46MLNTNVGZNPKX6UY/ > > @Adhemerval: have you had a look? > The only non-s390x changes of my patch are in: > elf/Makefile > elf/tst-glibc-hwcaps-cache.script > => There the libmarkermod6 libraries are added. > > As I don't have an arm, I've checked on x86_64, that the testcase > elf/tst-glibc-hwcaps-cache.c contains the libmarkermod6.so files in > glibc-hwcaps/z13-z17 directories by adding a "ldconfig -p" to the test. > > Any idea why those "Operation not permitted" regressions hits my patch, > but no others? > > Bye, > Stefan > > On 4/30/25 20:19, ci_not...@linaro.org wrote: >> Dear contributor, >> >> Our automatic CI has detected problems related to your patch(es). Please >> find some details below. >> >> In glibc_check master-arm, after: >> | glibc patch https://patchwork.sourceware.org/patch/111247 >> | Author: Stefan Liebler >> | Date: Tue Apr 29 13:28:58 2025 +0200 >> | >> | [PATCH v2] S390: Add new s390 platform z17. >> | >> | Hi, >> | need a V2: stfle_bits on stack in init_cpu_features_no_tunables() >> needs to be >> | zeroed before usage. If there is no more feedback, I will commit >> this patch shortly. >> | ... 41 lines of the commit log omitted. >> | ... applied on top of baseline commit: >> | 84977600dac math: Fix UB on sinpif (BZ 32925) >> >> Produces 90 regressions: >> | >> | regressions.sum: >> | Running glibc:debug ... >> | FAIL: debug/tst-fortify-syslog >> | Running glibc:dirent ... >> | FAIL: dirent/tst-readdir-long >> | FAIL: dirent/tst-readdir-zero-inode >> | ... and 99 more >> >> Used configuration : >> *CI config* tcwg_glibc_check master-arm >> *configure and test flags:* none, autodetected on >> armv8l-unknown-linux-gnueabihf >> >> If you have any questions regarding this report, please ask on >> linaro-toolchain@lists.linaro.org mailing list. >> >> -8<--8<--8<-- >> >> The information below contains the details of the failures, and the ways to >> reproduce a debug environment: >> >> You can find the failure logs in *.log.1.xz files in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3574/artifact/artifacts/artifacts.precommit/00-sumfiles/ >> The full lists of regressions and improvements as well as configure and make >> commands are in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3574/artifact/artifacts/artifacts.precommit/notify/ >> The list of [ignored] baseline and flaky failures are in >> * >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3574/artifact/artifacts/artifacts.precommit/sumfiles/xfails.xfail >> >> Current build : >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-precommit/3574/artifact/artifacts >> Reference build : >> https://ci.linaro.org/job/tcwg_glibc_check--master-arm-build/2743/artifact/artifacts >> >> Warning: we do not enable maintainer-mode nor automatically update >> generated files, which may lead to failures if the patch modifies the >> master files. > ___ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
