From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) by sourceware.org (Postfix) with ESMTPS id E5FB43858C83 for ; Fri, 21 Apr 2023 11:50:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E5FB43858C83 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-oa1-x35.google.com with SMTP id 586e51a60fabf-18777914805so10423850fac.1 for ; Fri, 21 Apr 2023 04:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1682077858; x=1684669858; 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=AGUTCKHdhSGbSILvh20YrzHuyx0nvA910xUI/o5k0Qs=; b=guJhNtZo8WaSihRI2aAYmkoiMm7D4WiEVS6aD3CKGshfrech7CtZwBdPPxyrmPHJDw 8L/4cP8rvY9dGXcqg9A6TKZmX5rPGDDYeWrE1qho6Ei0OCde/NAPIyduE6PNR9CwdxjR pOTMNbeSZJ/DFMQm2vVpxkLXImC6ls5deFoelNEgiDBjMUCQI66jQBGN+InVKrrQzQyD cSXlkU0pjwaPbtKDGTooDC1lbaVvAONxKS/dTAkP76QvjIHkV6giFjkl71ickY3uHEcE rJLhb4bkMnoh+Pz7IPNAUOEN7KdSIPEXCkYofHP7DDr/p3BNZ9kZ2xcdzmVs8LkAsKQv TMZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682077858; x=1684669858; 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=AGUTCKHdhSGbSILvh20YrzHuyx0nvA910xUI/o5k0Qs=; b=ZEd0lwk1lkO6h4PU3cCUojrQZKDRG7LmgJ0a7q+hcbs0fW5gcizTs15QunSVBd6hQD 0htmen4C2t1kQZGtO06MsgrgG5GXNzeB65WnMWAIvErBCBPphcUzPc3E2tjt2wX5uwY5 /ql0sYbVTeBglnzvuOSJGtuylZRtfMN/tNkqBTOPvGSb6NDNFSLlPQDWwpczxgCiENQM RQh+NstXm6iY8CkT67xQ/MWUE+TrL3RduZQeYzJkdpcARfLEjRfllM1CvjPKYPT9eM3l qmx2dBxIq0IoQt6g/qqT/HYwYhcJ7ITK52lV/vj2/3J91pUM9/avMbXs44JKe8Ujeybv jktg== X-Gm-Message-State: AAQBX9flCInkm21bFutAF7JUiFJryujzO90VJa2WZkyiV2jsYNya2SSc c0oX//t+j6jmyN7mdAPzTSaX8rp/buMmt54oSSv6Wg== X-Google-Smtp-Source: AKy350YM07JJyoJQkQlsK/shioxB+npOhc6VZaX7R4fm8SGGMGWhbIZNrxeEAttD1irifghwlkNlnQ== X-Received: by 2002:a05:6870:440a:b0:184:54b2:72f8 with SMTP id u10-20020a056870440a00b0018454b272f8mr3607508oah.8.1682077858091; Fri, 21 Apr 2023 04:50:58 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c3:333:20b7:b016:1b7f:fd25? ([2804:1b3:a7c3:333:20b7:b016:1b7f:fd25]) by smtp.gmail.com with ESMTPSA id k3-20020a4ab083000000b0053479edbc17sm1659612oon.33.2023.04.21.04.50.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Apr 2023 04:50:57 -0700 (PDT) Message-ID: <167de8d8-2598-fc32-c26c-749318d9451b@linaro.org> Date: Fri, 21 Apr 2023 08:50:54 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early Content-Language: en-US To: Sergey Bugaev Cc: "H.J. Lu" , libc-alpha@sourceware.org, bug-hurd@gnu.org, Samuel Thibault , Luca References: <20230420184220.300862-1-bugaevc@gmail.com> <20230420184220.300862-2-bugaevc@gmail.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=-7.8 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,T_SCC_BODY_TEXT_LINE 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 21/04/23 06:27, Sergey Bugaev wrote: > Hello, > > On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto > wrote: >> Can't you use a similar strategy done by 5355f9ca7b10183ce06e8a18003ba30f43774858 ? > > Do I understand it right that that is the moral equivalent of > > #define memcpy __memcpy_sse2_unaligned > > except that it works aat assembly level and so will catch implicit > calls to memcpy that the compiler may insert? Yes, that's the idea. > > Assuming for a second that we don't care about implicit memcpys (but > we should) and only about the explicit one made by the MIG runtime, we > could maybe even just do > > void * > __mig_memcpy (void *dst, const void *src, vm_size_t len) > { > - return memcpy (dst, src, len); > + return __memcpy_sse2_unaligned (dst, src, len); > } > > but that (as well as your proposal) would make *all* calls to memcpy > in this place go through the baseline version, even after the early > startup is done. Whereas my proposal attempted to avoid that -- unless > of course H.J. is right and this prevents the indirect relocation from > replacing the function pointer later, in which case it's even worse > because it would sabotage memcpy for the whole program and not just a > couple of files. It might work if you don't care about a different architecture than x86, and that's why I added the alias (so each architecture is free to name its ifunc variant). And the patch was exactly to handle the implicit created mem* call from compiler, so I think you should take it in consideration. And I trying to make reason why you need __mig_memcpy indirection for MIG.