From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) by sourceware.org (Postfix) with ESMTPS id 091003865C22 for ; Thu, 15 Feb 2024 18:52:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 091003865C22 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 091003865C22 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f2c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708023179; cv=none; b=ZpKPACBYMiBxY6isMawiPz1t6db+ZjKLp/Knxo8GKQazkc1g2ZDZB/DZPsrYdw3jjJ1snMqiXdAGWv2eTBL0F/AcuIvT7xrYMXllM71W2aDMScbVcXUxAFwWjAdQUYh7Ybu6saFr49IYexNdrpJNIRKEcoT+tdqM+ntAmZRy3KM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708023179; c=relaxed/simple; bh=NYt4XAYKWTYbECx2bhPDOEKHu191F5c4l8bLd+TYB3s=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=f/182qnwk/83qBQfPcr7QGbun9o5dYLqQPHh+rjExiKp0uOy4sT+rDbJaUUxNRsKY+W88adurP+vtNq7NGvHhi4hOOSRymtP7xqGTY1hzy6VwB6RFjEBndRgdieDlrd2O9PomQiRJLA/RC9L8WFiILK6ZZJuxVjahQMHKtTpSH8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf2c.google.com with SMTP id 6a1803df08f44-68f0de6fee2so5758086d6.3 for ; Thu, 15 Feb 2024 10:52:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708023176; x=1708627976; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=zsVpQhjFJ1V1S9H4T36sV9ke/5yRhDlqoPtc5GKR7L0=; b=n7TTW9zF1QmnJKcvpoPST1llFDcx3vzUwWzXe8uYBiGT0Ok7ocvH+gOzMFkgXoSQaZ GhhRkyF3fxTZIjtyid03VzY+yfgSHQ3FORd70QGR5uVO/WCI7Bg+sHiLxeRisqC67YZ+ i01FToJwjIzZbQMcW5Nj19UZ1oGvmQMgubxyT0X3DMDJWBMPD46Aej/QvYgWp+jpkxGS 3CgNN0F7Fn5ms6OriThfu4ZZe5z3GLuVExrstILhFP1m6VcKy01UM5gD+Lgg//cfBda0 0jd0dCG8L2fVR8aEGa6JhlSLh4drBYDqrctoSTI0W+e5e/WBI3+RxnBtIrVzbi/SSZoD LYjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708023176; x=1708627976; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=zsVpQhjFJ1V1S9H4T36sV9ke/5yRhDlqoPtc5GKR7L0=; b=hf2XZInHHdEoMHmmj05KCyZTgpI7HUNpHirm4YjoSls3HAOSm9tVKPU8zGqlprVW1T LMsYUyEoHKWy/B+tihBRZM81ASspfK6pvfTQiEKcexXowDag/61fcrk1Yi7Zi0uWBWvD d5OE0+0d64NwSvS7XcuhKZLwBiee57D9gu3nsDfRF+ieU78zxga9U0VFAMew0mlfI1yQ RstNtmFtNRZ6uv1MuF6P66uoOoei/5z2CfCrA853B4GOLOfLkQXq+0Ff20jA5JalUArj lkDreBO5+5qPdLZihKJkpoHoGsI/EIjVuQlFhj83obXjsec8ZM446k8GwMedpCbq4ZNN FhGA== X-Forwarded-Encrypted: i=1; AJvYcCWk+unAxHXm7Z6Vdg+Luq1LBh6Q6BrDZYQLpCuq0yVUt8Z9KEsnilIMoeL2Dvf95BoN/7qYnfLl28J5is1N8wICqV8lXNLg9yJ1 X-Gm-Message-State: AOJu0Yydy7xJDnS0/t0h/mGb29ULRpk/0HIP2wmEcJDkoncgtMzBLfRF LkXMndVW0Xso5buhjrgF7ptOHgsqiw+I1sZgkYoCO7vYvKPLEodkNWJjl/5C44d7SgJmjca3zk1 mSbHlRn7wNFmVYyHMOhPOFROXiF+Ng6J5yitP X-Google-Smtp-Source: AGHT+IFcAc/MarfmzpPx2NGXZNxAQs8jz8M3Z0g/4EZx/p0tIny8x5lTZksDjznROU0fjhFg9lfijTjr02pX3y1TPlM= X-Received: by 2002:a05:6214:3d0c:b0:68c:6649:51a6 with SMTP id ol12-20020a0562143d0c00b0068c664951a6mr3220108qvb.51.1708023176149; Thu, 15 Feb 2024 10:52:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: enh Date: Thu, 15 Feb 2024 10:52:44 -0800 Message-ID: Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface To: Jessica Clarke Cc: Palmer Dabbelt , Evan Green , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , Florian Weimer , slewis@rivosinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Thu, Feb 15, 2024 at 9:42=E2=80=AFAM Jessica Clarke = wrote: > > 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: > >>> > >>> > >>> > >>> On 14/02/24 11:31, Evan Green wrote: > >>> > > >>> > This series illustrates the use of a recently accepted Linux syscal= l that > >>> > enumerates architectural information about the RISC-V cores the sys= tem > >>> > is running on. In this series we expose a small wrapper function ar= ound > >>> > the syscall. An ifunc selector for memcpy queries it to see if unal= igned > >>> > access is "fast" on this hardware. If it is, it selects a newly pro= vided > >>> > 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 poin= ter > >>> > to the riscv_hwprobe() function in as the second argument to ifunc > >>> > selectors. A new inline convenience function can help application a= nd > >>> > library callers to check for validity and quickly probe a single ke= y. > >>> > >>> 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 tha= t > >>> Jessica proposed solutions was not fully sufficient to address all th= e > >>> ifunc corner cases. > >>> > >>> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.h= tml > >> > >> 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 :) > > > > The discussion's over here: https://inbox.sourceware.org/libc-alpha/202= 31017044641.pw2ccr6exvhtmhkk@google.com/ > > I was inclined to just ignore it: Florian explained what's going on wit= h the multiple libraries constraint, so we're kind of just going around in = circles at that point. > > > > 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 wi= th other kernels/libcs, > > Not binary compatibility, source compatibility. 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. > 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 achi= eve > that, and seems the simplest to me, but I=E2=80=99m not wedded to that, o= ther > 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. _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? 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. (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.) 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_). > Jess > > > but there's a ton of reasons why binaries aren't compatible between tho= se 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 t= hat's just how these things go. > > > > 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 eno= ugh to have much of an opinion -- sure maybe the multi-library IFUNC resolv= ing 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 bre= aking the ABI there. > > > > 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 argum= ent, that should be easy. Maybe we even just throw out a RFC patch to do i= t, unless I'm missing something the code is the easy part here (we're essen= tially just going back to one of the early versions, from before we knew ab= out this resolving order complexity). > > > >> 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. > > > > I'm OK with that, too. > > > >> > >> -Evan > >