From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 3A711386D618 for ; Thu, 15 Feb 2024 19:09:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A711386D618 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jrtc27.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jrtc27.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 3A711386D618 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::335 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708024169; cv=none; b=fa26FxKTtrGk2yqX0PBjwjeRyUiKH1dbQJOBcbt6eP0/xanZI6r3QW/DqGMBnIaS5onyBgCAr08fKOcSUpShqJLMjePwfediPTEy4zUplz6+lySN2Vc3gmolOdaUngiDLJzTH/sHRU/Sw32HMYhLNhM1lTLR+axsrkbc8YcdUgk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708024169; c=relaxed/simple; bh=fcof20l4BQPNRNW+H+tgnqZo0oUx6+SxF9n/5BuXba0=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=B80Kw8+mPDW9BrOCQHy8StItwHPMIC5vot6M5ghWdSRx/Z4L8RZ7C9YRGIUnLiAqjfrDbJYgyOw1WJckfi7g7dJMoAHsGk5WQJffHmhaFGRllWSsT8UgiVXNHUf0L5yU9Zxb7U8WoqLVkSD9LZHoSWd3GF/cFQtU32V0HMykVMU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-411a5b8765bso7581395e9.1 for ; Thu, 15 Feb 2024 11:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1708024165; x=1708628965; darn=sourceware.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5mmGEw+JBMKGqazwrSgx8YbG5peDJJXzEjTqkENemec=; b=bhBpiCPUjwfyPqLdSBDLEBWBcpCqZ0gb/gjJNgHWmZx8aJWh/tVDFy7ATnwX+DPCXx Zcte/iFa0vLxz2TLfwzk7RJrbblUFDad9y93zh5sW3k0DKO7eBXaA/XWgZnEi7PoyJXN vCxl+8GalScrus54F7B1EHLLiuwLZozZRn2Bvd2NNUDAWIqyhi9ylDBTNFpQqK1z0Z+X GW3XUXfVNyPFv/n3njb4X+1duegjkVnmvQSHVlsI2yr3iZh5DpdoEdu0wmx2TnqnxRez WJU5rd/BKdfczIrK6WvEjKXkBuLHq3wCop2JnFe8vNqa0nTis2HSl/lqPrTK+kFr3OIL Izvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708024165; x=1708628965; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5mmGEw+JBMKGqazwrSgx8YbG5peDJJXzEjTqkENemec=; b=HeQUMSvsr6O1o7wwCuJiA1MB/BWI3nYOrGkJpsLzsi05VkDzs7f2/4oFM7nFxsNTLQ UYvscQJeciaGeozEyfNj8hmMBn2vBlY/4CeJhT7V6QP3n2etKy+1ZY2hQWeECitnpvey T9pMuZtGk4UJ5oTxTABc7FGfGHHNFnAezklA0CJ0N+wkQZSgm9PY+7A1srf1Ycr4ZYlY jzv3/RFW58jmB9afmEcXtYALrjsW8SrtiubDnCcB2aF7Nv5ai99JcgiukyycHM7TKHmI 41vIW1CXQFfcr0bvMWVXygBi3mlJsWwNlTfQEGXolPjb0hsE96Y/SooeXppjs7S1rtfS CXxQ== X-Forwarded-Encrypted: i=1; AJvYcCUORhS4WbQXk8tA3m+Q/SsacuItyqvbSHfz/a7iQ1r75OnOAMyCekSzix8WQbawxPbaKDzVjsMEjobEXLNGDPdWcz0Dxkzl4PcB X-Gm-Message-State: AOJu0YxW7vi5AxEp5MclIQ6RK2oRlUw/sTTIuMkQw/2KPKqsXQEBjKe5 z+yzhSsscMfr0aiNOc0x6P0o+E8GDLxI7kDFOwNJmd2SxjcgLI0Aae/TNGS2U1M= X-Google-Smtp-Source: AGHT+IHC58aL3Wxb1elr8RgTfrbFLmopBjaxCsDWdm5POp+NBxdhipOL3Om7KFs7PqFeiUgiccdksw== X-Received: by 2002:a05:600c:4511:b0:40f:bbdb:4f2b with SMTP id t17-20020a05600c451100b0040fbbdb4f2bmr5691651wmo.19.1708024164838; Thu, 15 Feb 2024 11:09:24 -0800 (PST) Received: from smtpclient.apple (user-12fe-d1.svr-vpn-1.vpn.cl.cam.ac.uk. [2a05:b400:110:12fe::d1]) by smtp.gmail.com with ESMTPSA id h7-20020a05600c314700b00411e1782d33sm13226wmo.23.2024.02.15.11.09.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2024 11:09:24 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface From: Jessica Clarke In-Reply-To: Date: Thu, 15 Feb 2024 19:09:13 +0000 Cc: Palmer Dabbelt , Evan Green , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , Florian Weimer , slewis@rivosinc.com Content-Transfer-Encoding: quoted-printable Message-Id: <14287428-A2E8-4F77-BDBF-1B808FAE3D6A@jrtc27.com> References: To: enh X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spam-Status: No, score=-3.6 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,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 15 Feb 2024, at 18:52, enh wrote: >=20 > On Thu, Feb 15, 2024 at 9:42=E2=80=AFAM Jessica Clarke = wrote: >>=20 >> On 15 Feb 2024, at 16:50, Palmer Dabbelt wrote: >>> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >>>> On Wed, Feb 14, 2024 at 10:16=E2=80=AFAM Adhemerval Zanella Netto >>>> wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 14/02/24 11:31, Evan Green wrote: >>>>>>=20 >>>>>> This series illustrates the use of a recently accepted Linux = syscall that >>>>>> enumerates architectural information about the RISC-V cores the = system >>>>>> is running on. In this series we expose a small wrapper function = around >>>>>> the syscall. An ifunc selector for memcpy queries it to see if = unaligned >>>>>> access is "fast" on this hardware. If it is, it selects a newly = provided >>>>>> implementation of memcpy that doesn't work hard at aligning the = src and >>>>>> destination buffers. >>>>>>=20 >>>>>> For applications and libraries outside of glibc that want to use >>>>>> __riscv_hwprobe() in ifunc selectors, this series also sends a = pointer >>>>>> to the riscv_hwprobe() function in as the second argument to = ifunc >>>>>> selectors. A new inline convenience function can help application = and >>>>>> library callers to check for validity and quickly probe a single = key. >>>>>=20 >>>>> I still think we should address Jessica Clarke remarks for the = ifunc ABI [1]. >>>>> I recall that Florian has tried to address the ifunc ordering and = that >>>>> Jessica proposed solutions was not fully sufficient to address all = the >>>>> ifunc corner cases. >>>>>=20 >>>>> [1] = https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >>>>=20 >>>> I haven't invested the time yet in studying the resolver to = understand >>>> how feasible Jessica's suggestion is. I was sort of hoping Florian >>>> would chime in with an "oh yeah let's do that" or "no, it doesn't >>>> work". I suppose I still am :) >>>=20 >>> The discussion's over here: = https://inbox.sourceware.org/libc-alpha/20231017044641.pw2ccr6exvhtmhkk@go= ogle.com/ >>> I was inclined to just ignore it: Florian explained what's going on = with the multiple libraries constraint, so we're kind of just going = around in circles at that point. >>>=20 >>> I'm also not sure the argument makes a whole lot of sense in the = first place. The core of the argument seems to be around binary = compatibility with other kernels/libcs, >>=20 >> Not binary compatibility, source compatibility. >=20 > oh, yeah, obviously on the Android side i'm only talking about API, > not ABI. but i think Android-glibc source compatibility is more > meaningful -- by virtue of them both using Linux -- than anything > else. >=20 >> Yes, it=E2=80=99s part of that >> platform=E2=80=99s ABI, but it leaks into the source code by means of = the >> resolver=E2=80=99s type and arguments. I would much rather see a = standard IFUNC >> resolver interface that can be specified in the psABI as a >> cross-platform standard for any ELF-using OS that implements IFUNCs, >> since the moment glibc adopts this as its implementation of choice >> there=E2=80=99s no going back (without ugly =E2=80=9Cignore that = magic -1 argument, >> it=E2=80=99s there for historical reasons=E2=80=9D kinds of = situations). Adopting the >> stronger guarantees provided by FreeBSD=E2=80=99s rtld is one way to = achieve >> that, and seems the simplest to me, but I=E2=80=99m not wedded to = that, other >> suggestions that achieve the same end goal are just as welcome. Of >> course glibc is free to ignore me, too, with a =E2=80=9Cnot our = problem, deal >> with it, we=E2=80=99re the dominant OS=E2=80=9D, but that would seem = sad. >=20 > _not_ passing the function pointer to the ifunc resolver only > addresses source compatibility as far as the function _signature_ > goes, but does nothing for the _body_ of the function unless BSD > copies the Linux __riscv_hwprobe() syscall exactly. and tracks every > change after that. that seems unlikely? Yes, nobody=E2=80=99s going to copy that, but that doesn=E2=80=99t mean = it=E2=80=99s going to forever be the only interface that you could use. One function existing doesn=E2=80=99t stop another from doing so, but one argument being used = for one purpose does stop it being used for another. That is, in the proposed world where you just call __riscv_hwprobe directly and it works, there is a path towards having a cross-platform solution, namely defining a simplified, OS-independent interface for querying what extensions you have (which won=E2=80=99t cover all use cases, and doesn=E2=80=99t need = to, so long as it can deal with the ones that IFUNCs typically care about, i.e. simple questions like =E2=80=9Cdo I have V/Zb*/etc?=E2=80=9D), which could just = be a simple wrapper around __riscv_hwprobe on Linux. But if you pass __riscv_hwprobe as a function pointer as the solution to the problem, you=E2=80=99re tied to the Linux interface, and specifically the __riscv_hwprobe one at that, unless you want to add an argument every time you come up with an interface that software might want to use in a resolver for querying RISC-V information. I=E2=80=99m trying to look at = the bigger picture here rather than the very narrow view of =E2=80=9Cwhat=E2=80= =99s the easiest path to being able to write an IFUNCed memcpy in glibc for Linux=E2=80=9D. > plus, like i keep saying --- iOS and macOS don't have ifuncs (and i > don't think Windows does either?), so for any code that actually cares > about portability, handling your own function pointer is the only > truly portable game in town, and all this fussing about a niche > alternative is just noise. Firstly, none of those support RISC-V. Secondly, just because some OSes are more different than others doesn=E2=80=99t mean we shouldn=E2=80=99t = aim for as cross-platform interfaces as possible. Otherwise why are we bothering to have a RISC-V psABI at all rather than just letting glibc define whatever it wants? > (and we see that in practice, not just theory: open source libraries > have voted with their feet, and nothing we do here will affect that.) >=20 > i don't see that anyone actually gains anything from your proposal, > whereas the "pass the function pointer to the ifunc resolver" > workaround addresses actual problems with currently-shipping systems > in a way that doesn't require large and complex behavior changes (for > no gain _in the context of ifuncs_). Well, it=E2=80=99s a general solution to the specific problem seen here, = which arguably makes the glibc implementation of IFUNCs on RISC-V less special, as you can just call the normal __riscv_hwprobe if you want to. The gain is generality, which includes, but isn=E2=80=99t limited to, = being cross-platform. Jess >> Jess >>=20 >>> but there's a ton of reasons why binaries aren't compatible between = those systems. So if glibc just has a more complex IFUNC resolving = scheme and that ends up requiring the extra agrument, then users of = glibc have to go deal with that -- other systems/libcs might make = different decisions, but that's just how these things go. >>>=20 >>> Looks like Maskray is proposing making glibc's IFUNC resolving. = That's a generic glibc decision and I don't really understand this stuff = well enough to have much of an opinion -- sure maybe the multi-library = IFUNC resolving is overkill, but aside from doing some similar grep of = all the sources (or trying some builds and such) I'm not sure how to = tell if we're safe breaking the ABI there. >>>=20 >>> That said, we're not comitting to ABI stability until the release. = So if we decide to make a generic glibc change we can always go drop the = argument, that should be easy. Maybe we even just throw out a RFC patch = to do it, unless I'm missing something the code is the easy part here = (we're essentially just going back to one of the early versions, from = before we knew about this resolving order complexity). >>>=20 >>>> Alternatively, patches 1-3 of this series stand on their own. If = the >>>> ifunc aspect of this is gated on me doing a bunch of research, it >>>> might at least make sense to land the first half now, to get Linux >>>> users easy access to the __riscv_hwprobe() syscall and vDSO. >>>=20 >>> I'm OK with that, too. >>>=20 >>>>=20 >>>> -Evan