From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id 893AA3858C83 for ; Fri, 21 Apr 2023 14:28:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 893AA3858C83 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-ot1-x32d.google.com with SMTP id 46e09a7af769-6a5f6349ec3so893726a34.0 for ; Fri, 21 Apr 2023 07:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1682087307; x=1684679307; 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=ja1KjJBTRTbzvnxi5IW0vFD/+QXdwLYCZFXMtIX5rOM=; b=PnJwvH3W9qzwusRI96ea2/p57atwPycjUEgiuc2ERWs6QePjbNUGBDp2VGt3SI3kSL nsB4WzYPpHnfulM55CnXwvoGyB8k7HtJF91jmJgxMqVRHkZPQ/DTTU+W5/WHQLVgJUnj DKgN3KxcDQ39JCd/S+eeQJIsG9jCYMXfHrTPfIZMx4YfjMV2zfNPWQoh86iv+iK9mPIM RpWY3omgUnVV5g22xC0Bjv5mBxVmArQYdAecfpA6WgFRDfEj5zjq3No5uGtC+Fdt3VXJ 3/wyFDUd/dwAgANVx32TwkCI0hWSqIqZ9VndyUfXfrFX471dVYiX0RPOCd31Pb+d9AvG Hmwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682087307; x=1684679307; 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=ja1KjJBTRTbzvnxi5IW0vFD/+QXdwLYCZFXMtIX5rOM=; b=cJX4+nXkqOZaXO/cXc6m0stdluKt2OunoAY8Fwk5AqMAhpalq4l9yS1PyyCBrk2BUj m9Y+7tN3JTpN61nv83BlpDs8mcKY4LTWhF8GIB78j67IBzc9BYLmyBM2qTezPlcVxMyh O9P5BJjeXejiezf6BKRHXUuK6PXjo6NiJD3fuA0Ua3P3FlOTRh3U+m6nBz43c/CTVieV UBkrE4n9lbBeOb2aUP59+1+prEVJoAI3JYyXLZCLE0itu5NFQYYQb2iNVMlrDkrSd8Gl evZdTiHvzwexGqydKbWz0JBu8xWpOCwwhv/f3b7C7AiTCFYw1RM3jyjdwKrmtEIhAs1E nxCQ== X-Gm-Message-State: AAQBX9ceWtTtcavDVab5nFhsJ7uLSVfj3y330M01TeLMgZwNpIuio0wp 5gtIFsiAzZRp2KtAYBCFtZ3lyw== X-Google-Smtp-Source: AKy350bEwcVEaH/ahua+Tmj7Y1JyM6D9eEgCMLS8XXvKVSWjsTIaHABv1OAiNkMgV2EUql9gajlXWA== X-Received: by 2002:a9d:7596:0:b0:6a2:f3e2:d5b with SMTP id s22-20020a9d7596000000b006a2f3e20d5bmr2956443otk.9.1682087306897; Fri, 21 Apr 2023 07:28:26 -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 z2-20020a9d7a42000000b006a62c3af7bfsm494455otm.81.2023.04.21.07.28.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 21 Apr 2023 07:28:26 -0700 (PDT) Message-ID: <4ab79698-7131-b5af-7368-7e0359dc5aaa@linaro.org> Date: Fri, 21 Apr 2023 11:28:23 -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> <167de8d8-2598-fc32-c26c-749318d9451b@linaro.org> <8408f776-6e4f-9f3b-cf75-80853d83bec7@linaro.org> 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.4 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,URIBL_BLACK 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 10:56, Sergey Bugaev wrote: > On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto > wrote: >>> Yes, sure, I wasn't really suggesting we do that change. My point is, >>> I would like to make the same memcpy callsites both work during early >>> startup and start calling the more efficient implementation once early >>> startup is done -- if that's possible. >> >> That's the whole idea of dl-symbol-redir-ifunc.h, since it is explicit >> enable by TU. > > Then I must be misunderstanding how dl-symbol-redir-ifunc.h works > (please explain!), > > because I don't see how it would achieve that. Doesn't it change all > memcpy calls in the current translation unit (.c file) to always call > the baseline memcpy -- not only during startup, but even after the > startup has been completed? Indeed dl-symbol-redir-ifunc.h does not allow redirect the symbol in this dynamic way. But you can't really accomplish it without either hacking the ABI or using an override scheme, as we do for loader malloc (elf/dl-minimal.c) where the minimal malloc is replaced on final relocation phase. The memcpy/memset/memmove is tricky because since compiler is free to auto-generate calls to it we need to redirect it on a more direct way (as explicit inline asm alias). > > To be clear, this is about memcpy calls made *during* very early > startup, yes, but not *in* some special startup-only code (like > init-first.c and hurdstartup.c for instance): that startup-specific > code calls into the fairly generic code (mig_memcpy.c and the various > MIG-generated RPC routines) that is used both during this very early > startup and then much later during the normal runtime, and *that's* > what calls memcpy. I'd like for memcpy calls in that generic code to > both work during early startup and use the efficient memcpy > implementation later. If dl-symbol-redir-ifunc.h can achieve that, > please help me understand how. For Linux, the redirection is only used on very specific TU that can't really work with ifunc, and it is used only during static process initialization (like dl-support.c). The 56010b73e81e2 commit message describes what seems to be a really wacky scenario: lib{mach,hurd}user.so is relocated *before* libc.so; but they still call the libc.so symbols (because which seems to be the compiler generated memcpy call). The __mig_memcpy solution might work, but it is *really* hacky; but at same time I don't really have a solution for this Hurd mess...