From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by sourceware.org (Postfix) with ESMTPS id 8F8CF3858C66 for ; Tue, 9 Jan 2024 19:37:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F8CF3858C66 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8F8CF3858C66 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::132 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704829042; cv=none; b=qbUIjxvPgh/5zYcxF62if75DqWxK6RN5fvPsSX3+nZ0xWfsmPMetS33ELPzv8/RrxnyWvcJ4q9xMiybh8wgqeXgrHXyC5t+9TuJJUFpoouxML+v9jL+TkLvKk30jX0XTYdJOiaDF9ummzH4/QymGAPKSK4W/Ezgf/R3ZqaCJDoA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704829042; c=relaxed/simple; bh=c84JUQnSuJFxTqZ6ool6wv6YHMK3xtoO7R/tpCcG0jo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=l1Wl0eNLqzn6V5o8qKQsGvc0+u2AT8Unu0AdKltjzEM8JTblxc5nzSDxNLbe0kJZou9GMkafCN85dcjTSxxpcgbKq5XFObYr8FsxjoCAJpuWS1v9M5YkvesBPhXsWdnXdWf6fg06dlQ89J/qKSjx1IFA3udVvCyWYP7w8ML19Z4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-50eaa8b447bso3498512e87.1 for ; Tue, 09 Jan 2024 11:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1704829038; x=1705433838; 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=HOwKUekr+L6ZCI+22YFYpUDHKeti2hzB7oEmUGfUK2g=; b=bgGhhrcdsf/LuwvsmwPqTqHph0N7QLM54tDpEPkpZEqzfMgCHoCYVtKy9sqCTcBanf VXEEG/gCGHiyy3SeYKEI4CWZiRGhNr+FPIcS3mhWTM+IyRs9/4Q1+RFNm++DMNc3xaax 2PGRV5GUqpMC8a6FQS9KjCE0WLg9V5tEwVrXtctPJih/iI3DvARMfRGSa4hqxdvEUzzz CQR/1W9O5ZTAi+82vUneuHjELC1rJ/bCjmzaNkJdO/K2p+Boi7DlrBGNcxLJ7dX9PjjI 67i7TKMuUMerO2ntkJuu0XDgXhLqomDX40a405BUTQ2MAHJmlK93ERov/GI7A1V11lKr +15g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704829038; x=1705433838; 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=HOwKUekr+L6ZCI+22YFYpUDHKeti2hzB7oEmUGfUK2g=; b=HGLfkIrxCnCY67S4LyjyRT+tvGMsbf7SdreqrfJOAGZ1LZoTIcr+EsJ6qbvrat+OXm Ioa8RS9shhX0gBnPoRSzekZzwBQZIeFWKZ1zmFfuf63L5fcAt/x2Q1CWrZY0DPmGly3f S0lBjvpU8UqxabhUF99mq5+v35UBHsGHSKpQJwYNfiYLah+mlY8aL1u3i+LLZmp+jy6I tNSNUD2p5+q2LvuJVdR8Hi1fyITjbso9uSXwXK9UXvWHg5YVtnpgTDD7CDtqa1pIDmRg rt9GprZrluAQ2xQvwzeLAlbfhpZJDhlVXP6CafYerLk7Mslol3Mt5G0WXM4+6xU6+fHu Zc8w== X-Gm-Message-State: AOJu0Yyxb3WardEdUWzVLlmDCcMTSfnOdzCGj/cxYDIEw6669MeNAm9N f13w9+24CLA/qHKNmhALBwiyhHcGL+Ga8YOxAa36mxVjwmrJ1w== X-Google-Smtp-Source: AGHT+IGgsSUL/+UXSDFXYyBxujGbG6Xx/Zgg3p1BxOh43JdPKAYwhDgbA11pg2EXXDbEml7+h1kd3xYCDzUl8mabh/k= X-Received: by 2002:a05:6512:5c3:b0:50e:3082:1afe with SMTP id o3-20020a05651205c300b0050e30821afemr1263499lfo.22.1704829038016; Tue, 09 Jan 2024 11:37:18 -0800 (PST) MIME-Version: 1.0 References: <20231213211142.1543025-1-evan@rivosinc.com> <7f4ff036-cdd0-488d-a54c-1327e0ec0117@app.fastmail.com> <1a652f2f-4e3c-4052-a005-97d4e6f4337a@app.fastmail.com> In-Reply-To: <1a652f2f-4e3c-4052-a005-97d4e6f4337a@app.fastmail.com> From: Evan Green Date: Tue, 9 Jan 2024 11:36:42 -0800 Message-ID: Subject: Re: [PATCH v10 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface To: "Stefan O'Rear" Cc: "Stefan O'Rear via Libc-alpha" , Vineet Gupta , Sergei Lewis , Palmer Dabbelt , Florian Weimer , enh Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,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 Tue, Jan 9, 2024 at 11:10=E2=80=AFAM Stefan O'Rear = wrote: > > 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 parame= ter on > >> >> non-Linux ELF systems which do not provide riscv_hwprobe as a syste= m call. > >> >> Should it be passed as a null (or 1/-1) pointer in that case, or ar= e dynamic > >> >> linkers expected to provide some emulation of riscv_hwprobe of some= 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, othe= r > >> > 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 t= hat > >> 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 to= 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, alread= y > 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. Sure, the arguments here make sense to me, so +1 seems fine. > > > 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 glib= c > and it can no longer depend on Linux and a specific version of the glibc > dynamic linker. Specifically I meant the __riscv_hwprobe_one() static inline helper in patch 6, which is what's used by patch 7. Yeah, as far as I can tell the only way to run into trouble is copying that function over to a substantially different world. Maybe a comment would be sufficient then? -Evan