From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by sourceware.org (Postfix) with ESMTPS id B826E384DED1 for ; Thu, 15 Feb 2024 17:00:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B826E384DED1 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 B826E384DED1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::f30 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708016418; cv=none; b=IqLXskRRJPhpXJ0XGML2xanyfaKLS8DzaOJtOc/ab6hKh0Jbc8tVJWbFNa9Qhm3xVUNNlXjjLbKjH040gjQ0/t7BLEgCmCiF4cTHE826KccCu2XJaaKIo90q0Q6I8XpQ+w84/TlCo/qVHXBLSkgNw7OD+yMbDOBHmHrGn28ksx4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708016418; c=relaxed/simple; bh=rPSd0YEkhy4tX5+R8t19Qy5FxTSqeXZCv6KY8g49/Bk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=W8qiblLvNpO3GsBBb9kI+/Nx5jyP9RU/zE7oNOMZCIdAX0RX5+ZcJRiF1bktGJTszmXUkniGK/h0KAQnukc8oPlOUoFzQWDZKJvwZ99NFhZ8B16nzrYyMuKHlcEJucbU5TBe0T0tSdF+UniDdGI5c9ig6gO+PsGeHMQA+euM634= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-qv1-xf30.google.com with SMTP id 6a1803df08f44-68f15ff496dso4295706d6.3 for ; Thu, 15 Feb 2024 09:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708016415; x=1708621215; 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=IgHjC0ULmf0VI2skrWpwgOQq7pMBBtAEjxv4uu2Vfzc=; b=f8VQdrnt9DLRsEtLAoIAu305LmLi/YzNkgbak3hNg92h9yXrYBBHRAN6ttpB5yIJXk CvPJtOgnSw09kqi4ikV6eXgecpLqc4M46zCtH0SII7ozFqzwqrTM496moTExwGHNqIJb fyMBds1CJfM9SnDWPcLwq2f4vjlP5G5cZRWSMycUdYJOdtBB9FbEB+20ULGbD3QlENDb /PJAjVepCYj80yFHe0GtUBWK/f6kfh9JXA9Kxybertj0YA68zgq+ufCsoQE8iSwBTIRy UYHe/RJ+2V6q5X4raQzb6PYKiN/NwTTVfL34eTBPTfyWwgl5T+zjGUZ26U9Y1/hqMaLd PiTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708016415; x=1708621215; 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=IgHjC0ULmf0VI2skrWpwgOQq7pMBBtAEjxv4uu2Vfzc=; b=iq2Gzyg9TCK0IHjd2iyDiFVV8jN/JhRv/ziZGFs7FRcGSHJN0q5pTigpYarD+pO4qq S2iuMWSmCiZPjBz3TWGqpqIti0JR4PLEZyDGZAfY14Q55FxgUp+g1r92tt3VT5UjAN6W ES4w3cFDzOhb3bjfvSD98v92MuDcTemP/z8S7YPXArmYyZ27JvZF6ein/DAGzX5rXNAs SeV3LN9Ceb4s9PdJ6Aq5+x+14uzV3Ja7ndtGUKa00GpGcLvjfgsVNHHFNEDG29qlYdxQ +/j1qnw3OR2tsfbKIv2Bll2d/TPf/LBFdoz8bErmrU/iSAPiE4/LASNLMWZG9F6Pel0g gXcw== X-Forwarded-Encrypted: i=1; AJvYcCUKcrOp7xXvb4vDK7OLkaZchZ4Jjr0pZf12f7nD26C2HDC2UZNBej0se98j2qa1sD5oTSzsU8wSe59I4A0OSe90WjZrb4jQ7CeO X-Gm-Message-State: AOJu0Yye8zJ6qLqCO2+bBW6rV2AEVfhobHxf0Kd82YHjeU0GJ3LP8wyq /ZttPbTmztx9yUACThxHTVeopBrhC9nqMkOo+8Bg+gf7Zszil8WCf9Fi5FIiFRjJV1m0cz3bF8R nef2U1B4OZHVOo41gKc8tnjdaKZS3q1LAb0L0 X-Google-Smtp-Source: AGHT+IHMtuJntuC7vy26LBZbZ2kxC4EADUBXKfx4Y2n9lbqEMKczut1ckBqLM1jS1fn4tF3sI4lK3lHR/ECptTBl5g0= X-Received: by 2002:a0c:da84:0:b0:68c:82a3:a440 with SMTP id z4-20020a0cda84000000b0068c82a3a440mr2319668qvj.35.1708016414633; Thu, 15 Feb 2024 09:00:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: enh Date: Thu, 15 Feb 2024 09:00:03 -0800 Message-ID: Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface To: Palmer Dabbelt Cc: Evan Green , adhemerval.zanella@linaro.org, libc-alpha@sourceware.org, Vineet Gupta , fweimer@redhat.com, slewis@rivosinc.com, jrtc27@debian.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 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 8:50=E2=80=AFAM 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 syscall= that > >> > enumerates architectural information about the RISC-V cores the syst= em > >> > is running on. In this series we expose a small wrapper function aro= und > >> > the syscall. An ifunc selector for memcpy queries it to see if unali= gned > >> > access is "fast" on this hardware. If it is, it selects a newly prov= ided > >> > 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 point= er > >> > to the riscv_hwprobe() function in as the second argument to ifunc > >> > selectors. A new inline convenience function can help application an= d > >> > library callers to check for validity and quickly probe a single key= . > >> > >> I still think we should address Jessica Clarke remarks for the ifunc A= BI [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. > >> > >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.ht= ml > > > > 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/20231017044641.pw2ccr6exvhtmhkk@g= oogle.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. > > 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, 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. yeah, i struggle with the portability premise too. not least because macOS/iOS (which is obviously the most common "other platform" for me with my Android hat on) doesn't have ifuncs at all. that's quite a big blocker to any dream of portability. as i've said before, in a survey of all the open source libraries that go into Android, there are none that don't support macOS/iOS, and so there are none that actually rely on ifuncs. ifunc usage is limited to libc (which is why we libc maintainers get bikeshedded by stuff like this) and compiler-generated FMV stuff. i'd argue that "real people" (app developers) should probably be looking at the latter anyway, and it's our job to make that work (which happens once^Wtwice, in llvm and gcc). also, the fact that Android is doing what's proposed here (with the extra argument) means there'd be _some_ incompatibility even if glibc and FreeBSD didn't do that. (Android's only source incompatibility with glibc at the moment is the lack of the single-probe helper inline, which i fear will encourage _worse_ code, but suspect will actually be unused in practice anyway for the same "ifuncs are 'assembler' for libc/toolchain, and library/app developers doing stuff themselves will continue to use regular function pointers like they do today" reasons.) > 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. > > 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). > > > 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