From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by sourceware.org (Postfix) with ESMTPS id 595143858D20 for ; Fri, 1 Sep 2023 07:18:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 595143858D20 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-wm1-f43.google.com with SMTP id 5b1f17b1804b1-401b3ea0656so16144615e9.0 for ; Fri, 01 Sep 2023 00:18:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693552725; x=1694157525; 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=XDz3AXu6AZEBUl1Hl1w2KWxoptK8lF68Y6qQcGjwRA8=; b=h55OZw1Z1j8gFK4Fc/ekEnw7mg5qZsq3aQlKeHhb46AZvVtHwoppRtFFAX8rVS4v1W i+hpyIQQggIp9vKQsNaBbYnp+4q4dnSVBfcF/RLUjyAD5tsuC+uNQrnI86xrwlnfGDOT f4omGQVKj7yD6qN21C9Y5NKsRminFbjPJEvRtncLFO425ZDS1GrhORXt0zOaFMppfmf0 xY816o+V4jB8t0dCPz/kMq+UMmF26/QsCOh52nCeteuUqQa8d/RRCoMkpvNgcNXtVObj oeXIKK2TeXYdRLDmg9NM00H1mUU6LM1EkJam9+Kc3bftENkMfWxLDLZKtg4EnUdrocHz kZYg== X-Gm-Message-State: AOJu0Ywj37d2bVHnXvEc1DYHsDrifN39ikLPu5UkVVGaZtW6svQ6prn7 uBhbOCrhi7qqmUTX8I4X1duo5Vh0dLtawjMuHdI= X-Google-Smtp-Source: AGHT+IEK4KdpAg6asjRlB8r462I0ytbFkV+FBEcMZfKWv4aJPrAEMnC7DhHcYhNoYiwzPEU+SUhO34Clecq+R2b2tM8= X-Received: by 2002:a7b:c8ca:0:b0:401:519:c9 with SMTP id f10-20020a7bc8ca000000b00401051900c9mr1125479wml.13.1693552725076; Fri, 01 Sep 2023 00:18:45 -0700 (PDT) MIME-Version: 1.0 References: <87zg27bgjl.fsf@oldenburg.str.redhat.com> <90243b3d-740a-f391-089e-45d5ada7096f@linaro.org> In-Reply-To: <90243b3d-740a-f391-089e-45d5ada7096f@linaro.org> From: Mathieu Malaterre Date: Fri, 1 Sep 2023 09:18:33 +0200 Message-ID: Subject: Re: glibc-hwcaps for armv7 (neon-vfpv4) To: Adhemerval Zanella Netto Cc: Florian Weimer , libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 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 ! On Thu, Aug 31, 2023 at 5:30=E2=80=AFPM Adhemerval Zanella Netto wrote: > > > > On 31/08/23 09:08, Mathieu Malaterre wrote: > > 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-page= s > >>> 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 whi= ch subdirectories > >> are probed. I think either neon/vfp or vfp/neon should be among the > >> subdirectories. This functionality has since been removed from upstre= am > >> 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: > > . > > From your system configuration, it seems so. On a ubuntu22 I see: > > $ find /usr/ -iname libx264.so* > /usr/lib/i386-linux-gnu/libx264.so.163 > /usr/lib/i386-linux-gnu/i686/sse2/libx264.so.163 > /usr/lib/x86_64-linux-gnu/libx264.so.163 > $ /sbin/ldconfig -v 2>/dev/null | grep -A3 hwcap > /lib/i386-linux-gnu/i686: (hwcap: 0x0002000000000000) (from /etc/ld.so.co= nf.d/i386-linux-gnu.conf:3) > /lib/i386-linux-gnu/i686/sse2: (hwcap: 0x0002000000000001) (from /etc/ld.= so.conf.d/i386-linux-gnu.conf:3) > libx264.so.163 -> libx264.so.163 > > $ cat /etc/ld.so.conf.d/i386-linux-gnu.conf > # Multiarch support > /usr/local/lib/i386-linux-gnu > /lib/i386-linux-gnu > /usr/lib/i386-linux-gnu > /usr/local/lib/i686-linux-gnu > /lib/i686-linux-gnu > /usr/lib/i686-linux-gnu > > $ /lib/ld-linux.so.2 --help > [...] > Shared library search path: > (libraries located via /etc/ld.so.cache) > /lib/i386-linux-gnu (system search path) > /usr/lib/i386-linux-gnu (system search path) > /lib (system search path) > /usr/lib (system search path) > > No subdirectories of glibc-hwcaps directories are searched. ^very neat trick. I was not aware of this command. > Legacy HWCAP subdirectories under library search path directories: > i686 (AT_PLATFORM; supported, searched) > tls (supported, searched) > sse2 (supported, searched) > > So if you have '/usr/lib/i386-linux-gnu' add on your ld.so.cache, the > /i686/see will be search through legacy hwcap support. This has been confirmed by Florian since: you'd need glibc 2.37 to reproduce the behavior I am seeing in Debian/sid. > > > >>> 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). > > This is a ubuntu22 armhf chroot on aarch64: > > $ /lib/ld-linux-armhf.so.3 --help > [...] > Shared library search path: > (libraries located via /etc/ld.so.cache) > /lib/arm-linux-gnueabihf (system search path) > /usr/lib/arm-linux-gnueabihf (system search path) > /lib (system search path) > /usr/lib (system search path) > > No subdirectories of glibc-hwcaps directories are searched. > > Legacy HWCAP subdirectories under library search path directories: > v8l (AT_PLATFORM; supported, searched) > tls (supported, searched) > neon (supported, searched) > vfp (supported, searched) > > So both neon and vfp; I can not say exactly how debian is configured sinc= e both > ubuntu and debian carry out of tree patches; but I would expect them to b= e > similar regarding libc.