From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112329 invoked by alias); 3 Jan 2019 13:41:10 -0000 Mailing-List: contact libc-stable-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: List-Archive: Sender: libc-stable-owner@sourceware.org Received: (qmail 112300 invoked by uid 89); 3 Jan 2019 13:41:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:U*libc-help, thursday, Thursday, corner X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtpo56.poczta.onet.pl Received: from smtpo81.poczta.onet.pl (HELO smtpo56.poczta.onet.pl) (213.180.149.134) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 03 Jan 2019 13:41:07 +0000 Received: from DESKTOPRJ21ONS (unknown [94.75.102.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: marekzmyslowski@poczta.onet.pl) by smtp.poczta.onet.pl (Onet) with ESMTPSA id 43VpwC0Mkxz1XSbVl; Thu, 3 Jan 2019 14:40:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poczta.onet.pl; s=2011; t=1546522860; bh=H93eimTFwPuSQ0x0aUYQarL9lOyitmtu7gQ25Um9Os4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=Rhz4UAwUoWmkojB3nShVBmCQmraSvzu0mct3woppQ9lHuZVfsq/t48gnBr39m4g9T e/JgWgBt0J/FZIDJE9d11Vlgm9senkIFoa8OQ2jlpBdBgc5aE9K7EklsMK24IMjZhF AlmeFXOibntBy4wN677u/JSkV+pk0qbiG04AQ9Z0= From: To: "'Florian Weimer'" Cc: , References: <001b01d4a363$2fa4db50$8eee91f0$@poczta.onet.pl> <87k1jlvqlq.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87k1jlvqlq.fsf@oldenburg2.str.redhat.com> Subject: RE: Compile GLIBC without AVX support Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: <004101d4a369$f7080ae0$e51820a0$@poczta.onet.pl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGwHgrYW0QhwWJFLFmBodOOUeWsmQKqMTjipdFF94A= Content-Language: en-us X-ONET_PL-MDA-SEGREGATION: 0 X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00010.txt.bz2 Hello Florian, Thank you for your help. The "--disable-multi-arch" solved my issue =F0=9F= =98=8A=20 Regards Marek -----Original Message----- From: libc-stable-owner@sourceware.org O= n Behalf Of Florian Weimer Sent: Thursday, January 3, 2019 2:05 PM To: marekzmyslowski@poczta.onet.pl Cc: libc-stable@sourceware.org; libc-help@sourceware.org Subject: Re: Compile GLIBC without AVX support * marekzmyslowski: > I'm trying to compile the glibc 2.28 version without AVX support.=20 > However, whatever option I used, AVX files are still compiled and used. > I need this to use gdb record/replay tool. > Here is the configure command I used: > > ../configure --enable-mathvec=3Dno --prefix=3D/work/bin=20 > libc_cv_asm_avx512=3Dno libc_cv_asm_avx512dq=3Dno libc_cv_cc_avx512=3Dno= =20=20 > libc_cv_cc_sse2avx=3Dno > --disable-avx2 --disable-avx512 --disable-avx-128-fma > > After make the result is following: > > root@d93e9cc876c3:/work/glibc/build# readelf -Ws libc.so | grep avx > 1194: 0000000000000000 0 FILE LOCAL DEFAULT ABS=20 > strcasecmp_l-avx.os > 1198: 0000000000000000 0 FILE LOCAL DEFAULT ABS=20 > strncase_l-avx.os > 3257: 0000000000159070 337 FUNC LOCAL DEFAULT 13=20 > __memset_avx512_unaligned_erms > 3272: 0000000000158a40 9 FUNC LOCAL DEFAULT 13=20 > __mempcpy_chk_avx512_unaligned > 3276: 000000000014f1d0 1288 FUNC LOCAL DEFAULT 13=20 > __strncmp_avx2 . GDB needs to communicate to the process that there is no AVX support, by ma= sking CPU flags. I don't know if GDB has implemented that. You may have t= o use KVM or boot the system with a suitable clearcpuid argument on the ker= nel command line. If you do that, you won't have to rebuild glibc because = glibc will automatically stop using AVX. You can reduce AVX usage further by using --disable-multi-arch, but some us= es will remain if the CPU advertises support for AVX because there are some= corner cases where the dynamic linker needs to save and restore AVX-relate= d registers. Thanks, Florian