From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id F1DED3857BA4 for ; Tue, 10 Oct 2023 14:49:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1DED3857BA4 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-pf1-x42f.google.com with SMTP id d2e1a72fcca58-691c05bc5aaso5069903b3a.2 for ; Tue, 10 Oct 2023 07:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1696949350; x=1697554150; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=qdZgd6GME+09w/v3EpzqqN5dII8gKSiDM4fsQyDmhZY=; b=EhPxV+4Wp/IrTpAo73/OBAXIU44smtIYsJBxBMl7xRRmEIr6IsjVIEFXKImKklPDOu rerN0ZOIs9XBRw2pNjTsf2pg2ERsu/1dYbiDQarHE8PG65pwgyHTRUGRRrbao0j7AbkN ES4w+uDUS+MbbXsH48tWDRJ+m7XjKKNtfmhX9UzTS7e8WjbnodZHJ0Jga43H6ixTYShz vd2qIMf/MFRYJhrbgtpGP5jgwK4p7WsQxwzPyU8uaxkCC3yGSU8OOdlQ7xlnCIDkJFpE TfIOySe+NC4zHs+umBmKkLZWHualZJVsq2sPggySvRFUomJ3St63jA2zTPOJpvGnT0PK MM4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696949350; x=1697554150; h=content-transfer-encoding:in-reply-to:organization:from:references :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=qdZgd6GME+09w/v3EpzqqN5dII8gKSiDM4fsQyDmhZY=; b=HVMamh51jFm9Le6okqQZOPYwHzUR7OC8ZVd5Dh+EXpE5bNIyRLmaYPzSZQaDy1H2hT iqEznBnAXSupRxK5kw47Xz0vDknargLY1Sfuj4ZT7QiEco69w/oxhIVrMhOG05V98y+a 3/nXTqnS2S2tLie+GqVj/4KmgMEorJAdrGe9mKdRvtNVCp6GJh0Y971rw4qByxZsxSRQ P0l4tFvIMmyZIpkpqdFe8VG502rYkUxOGnB2Dicb81qgbboOs+aHhDySS011Pz/+8vN2 WqpmGdnxQpsTwStgqS9i4Mi5k0d9t6tbQ8ttCvSnD0l6fp0KCIVyT3BPyGzpgcapsWLg mG5w== X-Gm-Message-State: AOJu0Ywzzo/gTEzEBrWhALQ0VrRiZWoV+qMxRlJyWa+D5p6ofQPguVCO 0m+3uEym5YjjinyYXn10ptXgFJNK0lK1Qeg8MGeuqA== X-Google-Smtp-Source: AGHT+IGagYJ7bCR1uHWiK+NV8bdsiQdZjbN/olCrN5EuFPn1ktMW+ugEfmXXfP3fRoEMBLz+xqPj2Q== X-Received: by 2002:a05:6a00:21c9:b0:68f:c7c5:a73a with SMTP id t9-20020a056a0021c900b0068fc7c5a73amr20115474pfj.16.1696949349781; Tue, 10 Oct 2023 07:49:09 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c2:d09b:c9c9:35ee:f4f4:3b62? ([2804:1b3:a7c2:d09b:c9c9:35ee:f4f4:3b62]) by smtp.gmail.com with ESMTPSA id g2-20020a62e302000000b0069370f32687sm8581011pfh.174.2023.10.10.07.49.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Oct 2023 07:49:08 -0700 (PDT) Message-ID: <91cf42cc-e0c1-4d70-8b33-de838d40b357@linaro.org> Date: Tue, 10 Oct 2023 11:49:05 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: A question regarding the optimization of string functions in glibc. Content-Language: en-US To: yuucyf , libc-help@sourceware.org References: <35e2d94d.e6e.18b0cf26dce.Coremail.yuucyf@163.com> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <35e2d94d.e6e.18b0cf26dce.Coremail.yuucyf@163.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 07/10/23 22:41, yuucyf via Libc-help wrote: > Dear all, > > I have some questions to ask. > In the glibc source code, there are various string optimization functions for different PowerPC architectures in the sysdeps/powerpc/powerpc64/multiarch directory, such as xxx_power7, xxx_power8, xxx_power9, and so on. When building glibc, I've noticed that these source files generate .o files, and all of them are eventually merged into libc.a. My question is, if I use the strcpy function in my user code, which version of strcpy is actually linked? GCC supports specifying the CPU type using -mcpu, but how does the linker choose which version of strcpy to link? Can you please explain in detail the process of determining which function is linked? > I'm currently writing a test case on a Power8 platform that uses the strcpy string function. However, when I disassemble it after linking, I found that it's not using strcpy-power8.S. Since it's not using the optimized string function for the Power8 platform, I'm curious why there are assembly implementations of optimized string functions for multiple platforms like PowerPC, ARM, MIPS, and others. How does it determine which platform-specific optimized string function to use on a particular platform? Could someone kindly provide a detailed explanation? Thank you! The powerpc64 multiarch uses the IFUNC GNU extension [1], and each port might not provided the ifunc support for an specific symbol for static linking. The IFUNC is basically a way to select an implementation from a set at runtime, based on a provided callback. For powerpc the selection is done through AT_HWCAP/AT_HWCAP2 fields from auxv (provided by the kernel). For strcpy specifically, powerpc64 only provides the ifunc variant for the shared library. The libc.a will use the one provided by sysdeps/powerpc/powerpc64/multiarch/strcpy-ppc64.c which used the generic string/strcpy.c. [1] https://sourceware.org/glibc/wiki/GNU_IFUNC