From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 21FE93858C3A for ; Thu, 31 Aug 2023 12:08:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 21FE93858C3A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f49.google.com with SMTP id ffacd0b85a97d-31dcf18f9e2so587248f8f.0 for ; Thu, 31 Aug 2023 05:08:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693483720; x=1694088520; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iALoCbOpIr4+0cdr0ajoCs2pgwCvjzV90j4qFKEhGPA=; b=Lm8NYCkwuXdugOjXJ/mtNcK1k+bIK3oY/gT9U+c9vL42azNFkoz4cDiWAlI2QaB3VA wdbLaLFK04UNoadclso6sDc8bm0Z3wlAlminRJUua7bsINzQOY8Eyl5jFK32Ivp3occK 2svmi4AEheicjmg91ikXJrXpXfu09mgh+vQsuirUokvby8fSHaaWZbDLpXeJmi+lJT31 LgGKyetTSQclTnUNposhLvTFEAPZBMSt6wKcxzsZiFHL+cmozwxF7ZdeWSKzc69nh2lH Rbdz251QOQJvHQylbelI+nCvvO9G8TJ6gDiq08xZWH9Fk2zE3q02NnZadCOSTAjB3er0 a09A== X-Gm-Message-State: AOJu0YzCWPXICRBIMz0+m+s38QA9BqG2ZJX9uyt9+ZShGL6As26EvuKc Pxlk/IyCWcwfa01Bo5YB+coxB4nI2ILafPDuY0YXtKSU9u0= X-Google-Smtp-Source: AGHT+IGYYBxiiTnuzgj+zLG/+FiSO+ga/FFZSOETOO5UmRgi3SPEOXYALlqMh/a31XckFa3yaL26XwHdfMCwVgAuLU0= X-Received: by 2002:adf:e443:0:b0:319:7b66:7803 with SMTP id t3-20020adfe443000000b003197b667803mr4105151wrm.55.1693483719532; Thu, 31 Aug 2023 05:08:39 -0700 (PDT) MIME-Version: 1.0 References: <87zg27bgjl.fsf@oldenburg.str.redhat.com> In-Reply-To: <87zg27bgjl.fsf@oldenburg.str.redhat.com> From: Mathieu Malaterre Date: Thu, 31 Aug 2023 14:08:28 +0200 Message-ID: Subject: Re: glibc-hwcaps for armv7 (neon-vfpv4) To: Florian Weimer Cc: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Florian ! On Thu, Aug 31, 2023 at 1:24=E2=80=AFPM Florian Weimer = wrote: > > * Mathieu Malaterre: > > > Dear glibc maintainer, > > > > I fail to understand the ld.so man page (Debian/sid version: man-pages > > 6.03) for hwcaps support. Specifically I'd like to install a shared > > lib on a Debian/armhf system (baseline is neon-less) which was build > > with gcc option: > > > > -march=3Darmv7-a -mfpu=3Dneon-vfpv4 > > > > What subfolder should I be using ? > > You can use =E2=80=9CLD_LIBRARY_PATH=3D. /bin/true=E2=80=9D to see which = subdirectories > are probed. I think either neon/vfp or vfp/neon should be among the > subdirectories. This functionality has since been removed from upstream > glibc because it sometimes results in hundereds of extra openat system > calls. oh, thanks for the trick. Could you confirm my conclusion below (Debian/i386 sid system): % file /usr/lib/i386-linux-gnu/i686/sse2/libx264.so.164 /usr/lib/i386-linux-gnu/i686/sse2/libx264.so.164: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=3De66974d10aef77af7ed504266cde974d103484d6, stripped However: % /sbin/ldconfig -v 2>/dev/null | grep -A3 hwcap -> nothing same goes with: % LD_DEBUG=3Dlibs LD_LIBRARY_PATH=3D. /bin/true 3327956: find library=3Dlibc.so.6 [0]; searching 3327956: search path=3D. (LD_LIBRARY_PATH) 3327956: trying file=3D./libc.so.6 3327956: search cache=3D/etc/ld.so.cache 3327956: trying file=3D/lib/i386-linux-gnu/libc.so.6 3327956: 3327956: 3327956: calling init: /lib/ld-linux.so.2 3327956: 3327956: 3327956: calling init: /lib/i386-linux-gnu/libc.so.6 3327956: 3327956: 3327956: initialize program: /bin/true 3327956: 3327956: 3327956: transferring control: /bin/true 3327956: 3327956: 3327956: calling fini: [0] 3327956: 3327956: 3327956: calling fini: /lib/i386-linux-gnu/libc.so.6 [0] 3327956: 3327956: 3327956: calling fini: /lib/ld-linux.so.2 [0] 3327956: If I understand correctly the file /usr/lib/i386-linux-gnu/i686/sse2/libx264.so.164 cannot be used on Debian/sid/i386 system since libc used is: % /lib/i386-linux-gnu/libc.so.6 GNU C Library (Debian GLIBC 2.37-7) stable release version 2.37. Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 12.3.0. libc ABIs: UNIQUE IFUNC ABSOLUTE Minimum supported kernel: 3.2.0 For bug reporting instructions, please see: . > > Conversely how should I read the following: > > > > % sudo ldconfig -p | grep hwcap > > libfoo.so.160 (libc6,x86-64, hwcap: 0x0004000000000000) =3D> > > /lib/x86_64-linux-gnu/haswell/libfoo.so.160 > > libfoo.so.160 (libc6,x86-64, hwcap: 0x0000000000000004) =3D> > > /lib/x86_64-linux-gnu/avx512_1/libfoo.so.160 > > > > What does "haswell" / "avx512_1" subfolder implies in terms of gcc > > compile options ? > > It's complicated. Nowdays, on x86-64, you can use > glibc-hwcaps/x86-64-v3 and glibc-hwcaps/x86-64-v4, which are designed to > correspond to -march=3Dx86-64-v3 and -march=3Dx86-64-v4, and x86-64-v4 is= a > superset of x86-64-v3. Ok, thanks for the update. Could you just review what I see on my Debian/sid/armhf system: % cat /proc/cpuinfo | grep Features | uniq Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm % LD_DEBUG=3Dlibs LD_LIBRARY_PATH=3D. /bin/true 2964957: find library=3Dlibc.so.6 [0]; searching 2964957: search path=3D. (LD_LIBRARY_PATH) 2964957: trying file=3D./libc.so.6 2964957: search cache=3D/etc/ld.so.cache 2964957: trying file=3D/lib/arm-linux-gnueabihf/libc.so.6 2964957: 2964957: 2964957: calling init: /lib/ld-linux-armhf.so.3 2964957: 2964957: 2964957: calling init: /lib/arm-linux-gnueabihf/libc.so.6 2964957: 2964957: 2964957: initialize program: /bin/true 2964957: 2964957: 2964957: transferring control: /bin/true 2964957: 2964957: 2964957: calling fini: [0] 2964957: 2964957: 2964957: calling fini: /lib/arm-linux-gnueabihf/libc.so.6 [0] 2964957: 2964957: 2964957: calling fini: /lib/ld-linux-armhf.so.3 [0] 2964957: Based on the above, it seems glibc is setup to never search hwcaps optimized libraries on this system (even if neon/vfpv4 is supported by system). Thanks again for your kind help -M