From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) by sourceware.org (Postfix) with ESMTPS id DB3F33858D20 for ; Thu, 31 Aug 2023 15:30:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DB3F33858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oi1-x231.google.com with SMTP id 5614622812f47-3a99eeb95aaso542501b6e.2 for ; Thu, 31 Aug 2023 08:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1693495832; x=1694100632; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=KVcuMbCT0IhxaAOXrELfL+99tpI7Klj+o2rCnpeY5pI=; b=kMXTERciEj18YPVRr7WW5HIBWLX9wwMwP5MZPrt5UQ1Mx1UebToOhIMY+AAHNelHlr 1KlyNAIpTIZ40yGjg0R80dijN20+aA+SPcYUZyP2+/n5y87Hzgw6fWDVzBHy1aqPsROY zu3MjAs2AFS3YLLSZb2tD7N8+HLHkoQ0nykYq1RkoxpV70DWI53XeiKoDQgDcAjfLXS5 EYP3vaNpVkj9/f+kt0YZOXcqBONH8pzDDAlrBlezo0xxEtv4Ycc+E20plFbKwzrAXsPq LySzcsiLL8sG91FJQ+/R1yI7QZPgE4I+nW0+Juf553aBJ3q3kBlBNHbT18rqx9alDema DRCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693495832; x=1694100632; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KVcuMbCT0IhxaAOXrELfL+99tpI7Klj+o2rCnpeY5pI=; b=SX1x+K0JC5uo6WjBitez+DUhrFjcjVRuVecE6DFKWHSgEPfuGVnM3Qle2DXwqnADze pIyPn3cNjIdWC+yT3lZ4IrAIw4ZJzxxqhI9BkQL+zmunBA5jFNARvZDwODzlwsJtaoi4 LhwS/hSJTa7gce9lE7b5ru68/24m+9yc6yxYHRmCFIRNi2Zcp6RWcckPn+AB+YkZXHwK 59z0uu/Dre7VL8//qlnULH3mriJFjd/yrJzzWTylAaq8JN3f1AC6Ka0uGcnD1zZaZdV6 oyWhSA4kEymUANZqu4yLfNq89RoijiCi8ysGYRi16w5wrlMVZMk9LMPwln5AHVAg20sp bRqQ== X-Gm-Message-State: AOJu0YzhzGb79RTBnszv8wExa+V4rDqcZIBU1a4KO2HCXJDmu49dccKc yVl1gX1TaugX+xj9G/3CTJU9/w== X-Google-Smtp-Source: AGHT+IHmq0e1KkyntFtCr1XLefz1tLRObzcKoJu2TWOQaoCMlucvd6RwS6sNSl0tysT6J1h+FQnCVQ== X-Received: by 2002:a05:6808:1c2:b0:3a7:449c:8aae with SMTP id x2-20020a05680801c200b003a7449c8aaemr5914239oic.26.1693495832030; Thu, 31 Aug 2023 08:30:32 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:578c:c830:11c2:1b6:763? ([2804:1b3:a7c3:578c:c830:11c2:1b6:763]) by smtp.gmail.com with ESMTPSA id a19-20020a056808129300b003a724566afdsm844856oiw.20.2023.08.31.08.30.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Aug 2023 08:30:31 -0700 (PDT) Message-ID: <90243b3d-740a-f391-089e-45d5ada7096f@linaro.org> Date: Thu, 31 Aug 2023 12:30:28 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Subject: Re: glibc-hwcaps for armv7 (neon-vfpv4) Content-Language: en-US To: Mathieu Malaterre , Florian Weimer Cc: libc-help@sourceware.org References: <87zg27bgjl.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 31/08/23 09:08, Mathieu Malaterre wrote: > Hi Florian ! > > On Thu, Aug 31, 2023 at 1:24 PM 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=armv7-a -mfpu=neon-vfpv4 >>> >>> What subfolder should I be using ? >> >> You can use “LD_LIBRARY_PATH=. /bin/true” 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]=e66974d10aef77af7ed504266cde974d103484d6, stripped > > However: > > % /sbin/ldconfig -v 2>/dev/null | grep -A3 hwcap > -> nothing > > same goes with: > > % LD_DEBUG=libs LD_LIBRARY_PATH=. /bin/true > 3327956: find library=libc.so.6 [0]; searching > 3327956: search path=. (LD_LIBRARY_PATH) > 3327956: trying file=./libc.so.6 > 3327956: search cache=/etc/ld.so.cache > 3327956: trying file=/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.conf.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. 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. > >>> Conversely how should I read the following: >>> >>> % sudo ldconfig -p | grep hwcap >>> libfoo.so.160 (libc6,x86-64, hwcap: 0x0004000000000000) => >>> /lib/x86_64-linux-gnu/haswell/libfoo.so.160 >>> libfoo.so.160 (libc6,x86-64, hwcap: 0x0000000000000004) => >>> /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=x86-64-v3 and -march=x86-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=libs LD_LIBRARY_PATH=. /bin/true > 2964957: find library=libc.so.6 [0]; searching > 2964957: search path=. (LD_LIBRARY_PATH) > 2964957: trying file=./libc.so.6 > 2964957: search cache=/etc/ld.so.cache > 2964957: trying file=/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 since both ubuntu and debian carry out of tree patches; but I would expect them to be similar regarding libc.