From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by sourceware.org (Postfix) with ESMTPS id 3F23A3858407 for ; Tue, 9 Jan 2024 19:10:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F23A3858407 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=fastmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fastmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3F23A3858407 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=66.111.4.27 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704827418; cv=none; b=cyoFuKuQtIYJ2IALhS2BzPKoySTXfhFqqDph4cCtciUuOPUljWcoP6BQGh3Dc28NQBD4NMCbG6TNZQBIq4OENa1lQYh++Vg2ethOVAxJLvr1ZFShhQoRxwpWW7h/jaNqMXd/uMPeLSIGUp60qDexyOkP/DmeSK0XADrmNnRHDIs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704827418; c=relaxed/simple; bh=61ZB9+Z+t0PS4MrdOMjyO8Km0GT5XhfDOhuAapiGz+M=; h=DKIM-Signature:DKIM-Signature:MIME-Version:Message-Id:Date:From: To:Subject; b=jDKFdo6HKMHq4up3fc/PzyMV1rkqzmjIF/6VgZ3wiJ6LtfAu+YH25cM7qlz+B6UeezCsARc0H5WYiQBgVDApelz5rVnkODp2/vHSIJNxBvO62h3L4A7d6wL7ReySZmoFmATmkAODub03Y5dW1IsI+D+JPnURFq9MPhmHANnrC2Q= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1731D5C0129; Tue, 9 Jan 2024 14:10:16 -0500 (EST) Received: from imap50 ([10.202.2.100]) by compute3.internal (MEProxy); Tue, 09 Jan 2024 14:10:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1704827416; x=1704913816; bh=cFDBJwWybzqgdfjH6QSKOE9mD+l/ev/jxueB3aSzrWE=; b= pBSzJb0YozZG+53Y6tnmWfb7hj6eweb+DJDiwlJ2oomWjcwuowQe11R/2Hb2ZMJy mh0dwftG/yKSWkEpYUWHc0ue5YRLRR9Yn9C8rI+taRtu/dc4sIAjwOMmA9ek1Eb5 F5K0JpwaxhbOR1irb8o7j+UGj3ITFbHKj4FHLcX8ETkD5JegGdngxVzzGrzLGz/i BTnJbUCI/68FddCaEfWAaDic8MPwC2GxtlfnubMJzdGWJLFyUP2gP8wKh+kY4yD+ bPAJuzE9R5Ru6rjDMRemTHSloEo5yJ+/XZqKoxR73xVMbnrr6MaOcDmM6fZqaYd+ 8HT/uEVP8QiaIMlDosmDTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1704827416; x= 1704913816; bh=cFDBJwWybzqgdfjH6QSKOE9mD+l/ev/jxueB3aSzrWE=; b=z aOmeVWzbTvapeTcs61r5v789+W2jMRuilam0GRq6SEzE00X/uZxWj2QfRGSWALQw CBSrVX8ffgI7mOyVp5LZCgqzYjCME1Ycpz8KCPC0J3OQyaLePreREA12pBap6qsn XE1vUyW4iwS6PNHuPSEewKI9pqoJ7V2JD9JAigwuUyqVUg7dl6Pf5mqu4z18DQ1B PiEJXtsHvYz15G1v+IPDgqnWKXOiFiaZJtstU+26MnKtt3hYyeyDekyQ/EqVbxJD KUwcBZfWNvUymxyrhuiYJqBCdJEaMzgsIBidfCYaJ7eFLOYobe3R1GtrIr7/4En0 VdDhSfvmr6KFqWwM90KYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdehledguddvtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvvefutgfgsehtqhertderreejnecuhfhrohhmpedf ufhtvghfrghnucfqkdftvggrrhdfuceoshhorhgvrghrsehfrghsthhmrghilhdrtghomh eqnecuggftrfgrthhtvghrnhepgedvvdegveekteduhedvkeehveekhfeuveffkeethedv udekgeffhfeigeefveeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepshhorhgvrghrsehfrghsthhmrghilhdrtghomh X-ME-Proxy: Feedback-ID: i84414492:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id CFDC51700093; Tue, 9 Jan 2024 14:10:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-1364-ga51d5fd3b7-fm-20231219.001-ga51d5fd3 MIME-Version: 1.0 Message-Id: <1a652f2f-4e3c-4052-a005-97d4e6f4337a@app.fastmail.com> In-Reply-To: References: <20231213211142.1543025-1-evan@rivosinc.com> <7f4ff036-cdd0-488d-a54c-1327e0ec0117@app.fastmail.com> Date: Tue, 09 Jan 2024 14:09:55 -0500 From: "Stefan O'Rear" To: "Evan Green" Cc: "Stefan O'Rear via Libc-alpha" , "Vineet Gupta" , "Sergei Lewis" , "Palmer Dabbelt" , "Florian Weimer" Subject: Re: [PATCH v10 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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 Tue, Jan 9, 2024, at 1:41 PM, Evan Green wrote: > On Tue, Jan 9, 2024 at 10:30=E2=80=AFAM Stefan O'Rear wrote: >> >> On Tue, Jan 9, 2024, at 12:10 PM, Evan Green wrote: >> > On Tue, Jan 9, 2024 at 4:06=E2=80=AFAM Stefan O'Rear wrote: >> >> >> >> On Mon, Jan 8, 2024, at 12:06 PM, Evan Green wrote: >> >> > Any last thoughts on this series? I think the plan is to land it= shortly. >> >> >> >> I am still wondering what the intended ABI is for the second param= eter on >> >> non-Linux ELF systems which do not provide riscv_hwprobe as a syst= em call. >> >> Should it be passed as a null (or 1/-1) pointer in that case, or a= re dynamic >> >> linkers expected to provide some emulation of riscv_hwprobe of som= e variable >> >> fidelity? In the latter case, what features of riscv_hwprobe must= be emulated >> >> for the dynamic linker to claim ABI conformance? >> > >> > NULL would make the most sense IMO. Hwprobe is a Linuxism for sure,= so >> > code that uses hwprobe (either inside or outside an ifunc selector) >> > won't by default be portable across OSes. If Linux is consistently >> > good at defining the hwprobe bits and not breaking our own ABI, oth= er >> > OSes could in theory emulate the interface by exposing the same >> > keys/values. Though at least from our perspective that's not a goal. >> > >> > -Evan >> >> NULL was a mistake; we need to pass a non-NULL value in a1 to signal = that >> a2 is defined, since the current implementations pass NULL in a1 and >> garbage in a2. >> >> If a dynamic linker does not provide a Linux-compatible riscv_hwprobe= but >> does support features that are passed in a2..a7, would it be better t= o pass >> (long(*)())(-1) or a stub function that just returns 38 (+ENOSYS)? > > Oh great point, I hadn't connected those dots. I'm fine with either. > -1 would let them distinguish this case a little more explicitly, so > maybe that's better? +1 might be a better choice (match SIG_IGN rather than MAP_FAILED, alrea= dy a non-function in the uABI, and slightly fewer bytes for the branch). The stub function has a disadvantage of polluting the global ABI with Linux-specific error constants. No strong feelings here. > Is there a good spot to document this? The details of the IRELATIVE resolution process should probably go in riscv-elf-psabi-doc/riscv-elf.adoc . > Should I defend against that -1 value in my static helper function as > well by checking for it? It seems like I shouldn't need to since it's > in a Linux-specific header, but if there's a scenario for it then I'll > add it. > -Evan Do you mean select_memcpy_ifunc in patch 7? I'm inclined to say that it should be robust in case someone copies it into a library other than gli= bc and it can no longer depend on Linux and a specific version of the glibc dynamic linker. -s