From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97709 invoked by alias); 27 Aug 2018 13:09:54 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 96540 invoked by uid 89); 27 Aug 2018 13:09:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SEM_URI,SEM_URIRED,SPF_PASS autolearn=no version=3.3.2 spammy=H*p:D*org, phd, HContent-Transfer-Encoding:8bit X-HELO: mail-qk0-f175.google.com Received: from mail-qk0-f175.google.com (HELO mail-qk0-f175.google.com) (209.85.220.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Aug 2018 13:09:52 +0000 Received: by mail-qk0-f175.google.com with SMTP id j7-v6so10367777qkd.13 for ; Mon, 27 Aug 2018 06:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=to:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=XRDmpNTsxHNxiqpXGJfUoPMLJsMuN34/CbNi3kSMq2Y=; b=I2F3uJeG1RbWWXvHGP6rinj/yGh9D6nhqs5wEhZBQrPl+VwwC7m8UrY6cTYkmOof9Q /SZgz4zdHmfZY24jF6voUpL7+WNlSIPuyUsvhzr0cQh2g0Ew0lejhk5Wba8hefTaixHE +tYMx2iUdAIX9iiwiISVnQltyhSBZ5qBh559k= Return-Path: Received: from [10.0.0.106] ([201.82.189.205]) by smtp.googlemail.com with ESMTPSA id c21-v6sm8235396qtj.22.2018.08.27.06.09.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 06:09:49 -0700 (PDT) To: libc-help@sourceware.org References: From: Adhemerval Zanella Openpgp: preference=signencrypt Subject: Re: Multiple symbols at the same location Message-ID: Date: Mon, 27 Aug 2018 13:09:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-08/txt/msg00037.txt.bz2 On 25/08/2018 18:51, Derrick McKee wrote: > Hi, > > I am a PhD. student, and in my research I noticed that there are > several versions of memmove and memcpy that are included in statically > compiled binaries. I understand that this is done for optimization > purposes (and if that is not the case, let me know!). However, some > versions of memmove and memcpy are located in different places in > .text, while others have their symbols located at the same location in > .text. For example, __memcpy_avx512_unaligned and > __memmove_avx512_unaligned have the same address, however > __memcpy_ssse3 and __memmove_ssse3 are placed at different addresses. > I assume that this is also done for optimization purposes. > > Can someone give me an explanation as to why it makes sense to > separate one group of memory copying functions into two symbols, while > for others the same code is used? Thanks! These are ifunc [1] variants selected at runtime depending of the some criteria. For x86_64, it builds an intern data structure with current CPU features obtained from cpuid (sysdeps/x86/cpu-features.c) and then each selection can use these flags to select the best suitable variation. (check sysdeps/x86_64/multiarch/memcpy.c for instance). Now, it is possible to implement memcpy with memmove, although it might not be as optimized as possible. It is what memmove/memcpy for AVX512 does: * sysdeps/x86_64/multiarch/memmove-avx512-unaligned-erms.S 11 # include "memmove-vec-unaligned-erms.S" * sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S 564 strong_alias (MEMMOVE_SYMBOL (__memmove, unaligned), 565 MEMCPY_SYMBOL (__memcpy, unaligned)) [1] https://sourceware.org/glibc/wiki/GNU_IFUNC