From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 03CA2384CB97 for ; Thu, 15 Feb 2024 17:42:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 03CA2384CB97 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 03CA2384CB97 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::332 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708018959; cv=none; b=LWinde6uY7eBJKHXUc+2u2OAF6wlQyM+g2gX9bV9KTYmJtL0SQTR+tiG4d23vp0uZhzTs4/N9MC5Bnzcd3GDkCQsSV58CGeoR6lbIL7jRrBJQoGCl8GCffE1lKMbGosR2rmDmeU4PDM+/Gcn0dL3y669AyOt0L+97GMItq41ZjY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708018959; c=relaxed/simple; bh=4ppOs1nIM90rf+EJhSihNaNdL4dHR3kyfTkf4LFygHM=; h=DKIM-Signature:Mime-Version:Subject:From:Date:Message-Id:To; b=glNr4k4l22nF1+0rk8Aun8/XQYcs6DcYE9vGwCnffcpytRtcL/zr3ft4M+t9sPH/dwRQH1p3v7M7tOgPE7eHKQI7s+jlmD7fBpybVsXT/75gHhZY6QOqlkrhcP2X0t6746mwvg3Wov5m1KLTKcj+1We0EAfHQZMmmsD5QeL2csY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-411a5b8765bso7097765e9.1 for ; Thu, 15 Feb 2024 09:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jrtc27.com; s=gmail.jrtc27.user; t=1708018955; x=1708623755; 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=QMKkInFOvBHcHWE2LO4oIuImyH/pi+C9uh5VZakBTVk=; b=MNjkmkh0bKhK+dvHYneDdl491fevVEB3hAvoJKGeUIDLzSxlYv4RksPoVq7m5ed07V GCVT+s+mYXwaxt58AHqxjx4Xxg9RpGLQ9uLzOkJwXUz/4cZMqAZN2JzGpgaefig0E/FS UUyOUIy2AN2zBKoQv84on/3CihLRPIlerxFRgLdHgeLpSTNyRGNTZ1faUdCPvrTle/9m +43IIBBz9t0uhjLy2IBJuVLmJcQ4xlq+acq962UELmCwjOLQKv0i2SpxdLCMiz37wzS6 6iEEyo2GbQqFmK1svrrwKELI4AhzhaBl1Ti0qWfTACwoNLWTtdkYq/GSbJBa+4xOaIOm rQ4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708018955; x=1708623755; 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=QMKkInFOvBHcHWE2LO4oIuImyH/pi+C9uh5VZakBTVk=; b=W46nFbsNHK51alzvlnilMAhDq+eBwpXtnBCJ/iU9rDn8tBmxUJ1XU/bOeVt1nBdDI6 PWHFFTht/rZVVKUcN34RbXsGx9rpFmWLAEZ60NdLuIxQEgAmhfZBjlefpLUsy8ZCHryc JTCBDULZLY7h3yrXy61p0Z7xYGeG+nkl61zrFHvdyEHApUvGBKKvbl2mbP6h+CAbppi/ yIWi+/lqmmzf3m5T8GWXNh6r4I68TaW51iJLItkJykdvnUHiluUmfNiIEWq0UePYQh6/ FPf+nTExiHb7Thq+u356wU2dfWR46XCWLkhCohTuvOOqfylaHD8vmEUxo+ONZvRLHUkN B40A== X-Forwarded-Encrypted: i=1; AJvYcCVCoL7ltx2wRVeweZnI+bN4yba6nfwotnOZW4sQJZGZyODcHmmM0FdUsXT+DiXuMjvyyuf46bVjQDRWUQ37vimvk1T/BVMuXGct X-Gm-Message-State: AOJu0Yy7DSYO4NSMFySuTaxYR2k5KmaeK7BB3ap1afWka5LJDf/QsZSi hLr1haSJWRaTVDgYfCJ2LIF+THrEWLs+RtVn3D2nNTFemU/WO3b4wdOaFywxUyQ= X-Google-Smtp-Source: AGHT+IHZFgBNE0VmjyQK3nsAas8Rmdi99Aa5uOAGNRYY+dCOgxCbyHmiqbkDT/2MCWSze+Z6qB14YA== X-Received: by 2002:a05:600c:6004:b0:410:e97c:a405 with SMTP id az4-20020a05600c600400b00410e97ca405mr2292555wmb.15.1708018955571; Thu, 15 Feb 2024 09:42:35 -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 s5-20020adfecc5000000b0033ce5b3390esm2409267wro.38.2024.02.15.09.42.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2024 09:42:35 -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 17:42:24 +0000 Cc: Evan Green , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , Florian Weimer , slewis@rivosinc.com Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Palmer Dabbelt X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spam-Status: No, score=-3.7 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 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: >>> > >>> > 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. >>> > >>> > 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, Not binary compatibility, source compatibility. 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. Jess > 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