Message ID | 20240214143159.2951158-1-evan@rivosinc.com |
---|---|
Headers |
Return-Path: <libc-alpha-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EC958385E036 for <patchwork@sourceware.org>; Wed, 14 Feb 2024 14:32:39 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id D66EA385C422 for <libc-alpha@sourceware.org>; Wed, 14 Feb 2024 14:32:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D66EA385C422 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 D66EA385C422 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::431 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707921138; cv=none; b=uuafpFWdYwri2IOUagGpYbLYQccxyjMk3cDqGK/PVpx0cAar7cbamACMtG2juZzHDx51XSJEBSYZh00a46BlIMAdMfA+oLEr932epnP3GmkXEh7JkHP2C3cFC/ooMK+Rjn3qYvagHoHwf/XgytsGqzESRZlvq37jJ8IeSfwQ7iw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707921138; c=relaxed/simple; bh=TpOnz2sE8nQM9aaKbxDOwh5AvvrIe/p9KXdkeIOe/eI=; h=DKIM-Signature:From:To:Subject:Date:Message-Id:MIME-Version; b=RBJ7O8VHaFbxQ4CWYHwLRDnqlGD5SIHOgnxsUdwD+EPWN2FZC6tn9jA4QZeSYcmWWQsi7CfTfSzrSsApM3o1kVtTMbebxP4TJMOdjJRfTjOKgoGbyqkuFnj0gBYsvZkuhN9y3k0GlopxGMr3cYCJC8s9uMbF+tGnfSOPPhTosCo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6e09493eb8eso705309b3a.1 for <libc-alpha@sourceware.org>; Wed, 14 Feb 2024 06:32:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1707921133; x=1708525933; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=/+8bKOCqxB2d/atVLRy9udIkWKOdfmPo+RmBaXSJQUs=; b=VPnrkzOEYuFkywl4JTIC5wKSvm5W1zwPyqNe8GUstVNqCZtvxjN/N7JuRbINfu8XXz KKSnMakodyRzAIYAUbdyBSx6asWXzTyfToSaMWLkZ3aKauzkQfjmGFZgcERfU6V5A+tA cdkOwoFJzCF703PixNTkLW/2DznU10hnfBt4pckNFSdD8nA9Cbqo0cemAU11WNiMBGu/ vzwzBIEux/u8C1rLMMBXPp1KevVW0IPl1OhS/MAy0EWj9q8lCISRYpwKRvp16MMSNqrC HnfqOUxdRYpm7dtoRogyhUuPK0RpY5rPCd9YU7Wi8w1O0gyuyuYOZ4m6GDdzJPAMylxM 8dLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707921133; x=1708525933; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/+8bKOCqxB2d/atVLRy9udIkWKOdfmPo+RmBaXSJQUs=; b=s4fDADJBZM7rzPU1ab7l66Gn5wSeIE3AUKbw4Yd9C+7Zfh0+aGcdqB1hVBLEiGT7J5 H/VpsdoyVFZ7VaHUEdy07lZI7x/q9qE2yocpavj2d7LAqq/gH8/5mFrsgwPURtPVVJEu u4f5Aj3LfS6Hwg1irEXD8Szatdj31cVVlWygek2Wv+zzw82ODzgL9+rJ7u+42bTLCcx+ LhmS/8WfEH5tlzlzg/HVESbBneTr3RvSMMFeoW4IVetDZkSIr0AblTkaDJM7TIensT2I Hixw7WEI5rWEiwKVSjkt1UNDPTl5DFaqa15QIlAHe0choq7N9MDJQi2iDlj6tOxU8piX TRAA== X-Gm-Message-State: AOJu0Yz7QqG7WHj0lhjZnyzlnqnSP85xYCj6Bhpf/CjmMvwNN4fkI6w4 32GkF3BlmeYldclHXMLi/nzwJe5ch5K14UgJxbIuHrocWzOpsoCxm+El/uj1fMsd7Vc3lFS77k2 O X-Google-Smtp-Source: AGHT+IHUDKWziBa9p7PGaQ+35+W2A3vVSHJWsesGgIRM47pe836rNQGy9pwO1bvKBliIrSoR3qhJAg== X-Received: by 2002:a05:6a21:918a:b0:19e:9647:dad3 with SMTP id tp10-20020a056a21918a00b0019e9647dad3mr2888061pzb.12.1707921133309; Wed, 14 Feb 2024 06:32:13 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCWSJ7Fgtallmx7ZvVH/M3avPWPSOT5aIyonmYTB0whAC0R0f3+tOq5H2+893pE+5SDvTNFdyq3hRXPS+Td9px28teIPXMqRvl/t28TrZ2f0tvVPpfkQVOuNq4WVtW0KvwRXC1C3QI5e6Rh3l7ruZLuiYhVicveAHV/E95pDvSJG Received: from evan.ba.rivosinc.com ([64.71.180.162]) by smtp.gmail.com with ESMTPSA id k21-20020a635a55000000b005dc98d9114bsm1140255pgm.43.2024.02.14.06.32.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Feb 2024 06:32:12 -0800 (PST) From: Evan Green <evan@rivosinc.com> To: libc-alpha@sourceware.org Cc: vineetg@rivosinc.com, Florian Weimer <fweimer@redhat.com>, slewis@rivosinc.com, palmer@rivosinc.com, Evan Green <evan@rivosinc.com> Subject: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Date: Wed, 14 Feb 2024 06:31:51 -0800 Message-Id: <20240214143159.2951158-1-evan@rivosinc.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.4 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 X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Libc-alpha mailing list <libc-alpha.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/libc-alpha/> List-Post: <mailto:libc-alpha@sourceware.org> List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>, <mailto:libc-alpha-request@sourceware.org?subject=subscribe> Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org |
Series |
RISC-V: ifunced memcpy using new kernel hwprobe interface
|
|
Message
Evan Green
Feb. 14, 2024, 2:31 p.m. UTC
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. The memcpy implementation is independent enough from the rest of the series that it can be omitted safely if desired. Performance numbers were compared using a small test program [1], run on a D1 Nezha board, which supports fast unaligned access. "Fast" here means copying unaligned words is faster than copying byte-wise, but still slower than copying aligned words. Here's the speed of various memcpy()s with the generic implementation. The numbers before are using v4's memcpy implementation, with the "copy last byte via overlapping misaligned word" fix this should get slightly better. memcpy size 1 count 1000000 offset 0 took 109564 us memcpy size 3 count 1000000 offset 0 took 138425 us memcpy size 4 count 1000000 offset 0 took 148374 us memcpy size 7 count 1000000 offset 0 took 178433 us memcpy size 8 count 1000000 offset 0 took 188430 us memcpy size f count 1000000 offset 0 took 266118 us memcpy size f count 1000000 offset 1 took 265940 us memcpy size f count 1000000 offset 3 took 265934 us memcpy size f count 1000000 offset 7 took 266215 us memcpy size f count 1000000 offset 8 took 265954 us memcpy size f count 1000000 offset 9 took 265886 us memcpy size 10 count 1000000 offset 0 took 195308 us memcpy size 11 count 1000000 offset 0 took 205161 us memcpy size 17 count 1000000 offset 0 took 274376 us memcpy size 18 count 1000000 offset 0 took 199188 us memcpy size 19 count 1000000 offset 0 took 209258 us memcpy size 1f count 1000000 offset 0 took 278263 us memcpy size 20 count 1000000 offset 0 took 207364 us memcpy size 21 count 1000000 offset 0 took 217143 us memcpy size 3f count 1000000 offset 0 took 300023 us memcpy size 40 count 1000000 offset 0 took 231063 us memcpy size 41 count 1000000 offset 0 took 241259 us memcpy size 7c count 100000 offset 0 took 32807 us memcpy size 7f count 100000 offset 0 took 36274 us memcpy size ff count 100000 offset 0 took 47818 us memcpy size ff count 100000 offset 0 took 47932 us memcpy size 100 count 100000 offset 0 took 40468 us memcpy size 200 count 100000 offset 0 took 64245 us memcpy size 27f count 100000 offset 0 took 82549 us memcpy size 400 count 100000 offset 0 took 111254 us memcpy size 407 count 100000 offset 0 took 119364 us memcpy size 800 count 100000 offset 0 took 203899 us memcpy size 87f count 100000 offset 0 took 222465 us memcpy size 87f count 100000 offset 3 took 222289 us memcpy size 1000 count 100000 offset 0 took 388846 us memcpy size 1000 count 100000 offset 1 took 468827 us memcpy size 1000 count 100000 offset 3 took 397098 us memcpy size 1000 count 100000 offset 4 took 397379 us memcpy size 1000 count 100000 offset 5 took 397368 us memcpy size 1000 count 100000 offset 7 took 396867 us memcpy size 1000 count 100000 offset 8 took 389227 us memcpy size 1000 count 100000 offset 9 took 395949 us memcpy size 3000 count 50000 offset 0 took 674837 us memcpy size 3000 count 50000 offset 1 took 676944 us memcpy size 3000 count 50000 offset 3 took 679709 us memcpy size 3000 count 50000 offset 4 took 680829 us memcpy size 3000 count 50000 offset 5 took 678024 us memcpy size 3000 count 50000 offset 7 took 681097 us memcpy size 3000 count 50000 offset 8 took 670004 us memcpy size 3000 count 50000 offset 9 took 674553 us Here is that same test run with the assembly memcpy() in this series: memcpy size 1 count 1000000 offset 0 took 92703 us memcpy size 3 count 1000000 offset 0 took 112527 us memcpy size 4 count 1000000 offset 0 took 120481 us memcpy size 7 count 1000000 offset 0 took 149558 us memcpy size 8 count 1000000 offset 0 took 90617 us memcpy size f count 1000000 offset 0 took 174373 us memcpy size f count 1000000 offset 1 took 178615 us memcpy size f count 1000000 offset 3 took 178845 us memcpy size f count 1000000 offset 7 took 178636 us memcpy size f count 1000000 offset 8 took 174442 us memcpy size f count 1000000 offset 9 took 178660 us memcpy size 10 count 1000000 offset 0 took 99845 us memcpy size 11 count 1000000 offset 0 took 112522 us memcpy size 17 count 1000000 offset 0 took 179735 us memcpy size 18 count 1000000 offset 0 took 110870 us memcpy size 19 count 1000000 offset 0 took 121472 us memcpy size 1f count 1000000 offset 0 took 188231 us memcpy size 20 count 1000000 offset 0 took 119571 us memcpy size 21 count 1000000 offset 0 took 132429 us memcpy size 3f count 1000000 offset 0 took 227021 us memcpy size 40 count 1000000 offset 0 took 166416 us memcpy size 41 count 1000000 offset 0 took 180206 us memcpy size 7c count 100000 offset 0 took 28602 us memcpy size 7f count 100000 offset 0 took 31676 us memcpy size ff count 100000 offset 0 took 39257 us memcpy size ff count 100000 offset 0 took 39176 us memcpy size 100 count 100000 offset 0 took 21928 us memcpy size 200 count 100000 offset 0 took 35814 us memcpy size 27f count 100000 offset 0 took 60315 us memcpy size 400 count 100000 offset 0 took 63652 us memcpy size 407 count 100000 offset 0 took 73160 us memcpy size 800 count 100000 offset 0 took 121532 us memcpy size 87f count 100000 offset 0 took 147269 us memcpy size 87f count 100000 offset 3 took 144744 us memcpy size 1000 count 100000 offset 0 took 232057 us memcpy size 1000 count 100000 offset 1 took 254319 us memcpy size 1000 count 100000 offset 3 took 256973 us memcpy size 1000 count 100000 offset 4 took 257655 us memcpy size 1000 count 100000 offset 5 took 259456 us memcpy size 1000 count 100000 offset 7 took 260849 us memcpy size 1000 count 100000 offset 8 took 232347 us memcpy size 1000 count 100000 offset 9 took 254330 us memcpy size 3000 count 50000 offset 0 took 382376 us memcpy size 3000 count 50000 offset 1 took 389872 us memcpy size 3000 count 50000 offset 3 took 385310 us memcpy size 3000 count 50000 offset 4 took 389748 us memcpy size 3000 count 50000 offset 5 took 391707 us memcpy size 3000 count 50000 offset 7 took 386778 us memcpy size 3000 count 50000 offset 8 took 385691 us memcpy size 3000 count 50000 offset 9 took 392030 us The assembly routine is measurably better. [1] https://pastebin.com/DRyECNQW Changes in v12: - Updated version to 2.40 Changes in v11: - Update copyright year (Adhemerval) - Update copyright year (Adhemerval) - Remove superfluous 'signed' (Adhemerval) - Put helper before __END_DECLS (Adhemerval) - Add comment about +1 on non-Linux systems (Stefan) - Update copyrights to 2024 (Adhemerval) - Avoid implicit check in select_memcpy_ifunc (Adhemerval) - Remove hidden_def (__memcpy_noalignment) (Adhemerval) Changes in v10: - Remove spurious 5 from syscall patch (Adhemerval) - Use one item per line in Makefile (Adhemerval) - Remove double underscores from __riscv_hwprobe definition (Adhemerval) - Use only spaces in macro definitions of hwprobe.h (Adhemerval) - Introduced INTERNAL_VSYSCALL patch - Remove leading underscores in definition (Adhemerval) - Remove spurious 5 from INTERNAL_SYSCALL_CALL (Adhemerval) - Use new INTERNAL_VSYSCALL macro instead (Adhemerval) - Hand in pointer to __riscv_hwprobe(), not vDSO function - Avoid implicit comparisons (Adhemerval) - One line per function in Makefile for memcpy (Adhemerval) - Space before argument-like things (Adhemerval) Changes in v9: - Alphabetize new entries in libc.abilist (to pass checks) - Fix a couple of typos causing powerpc not to build (build-many-glibcs) - Use __inline rather than inline so c89 compiles (build-many-glibcs) Changes in v8: - Fix missed 2.39 in abilists (Joseph) - Just return -r (Florian) Changes in v7: - Bumped Versions up to 2.39 (Joseph) - Used INTERNAL_SYSCALL_CALL, and return positive errno to match pthreads API (Florian). - Remove __THROW since it creates a warning in combination with the fortified access decorators. - Use INTERNAL_VSYSCALL_CALL (Florian) - Remove __THROW from function pointer type, as it creates warnings together with __fortified_attr_access. - Introduced static inline helper (Richard) - Use new helper function in memcpy ifunc selector (Richard) Changes in v6: - Prefixed __riscv_hwprobe() parameters names with __ to avoid user macro namespace pollution (Joseph) - Introduced riscv-ifunc.h for multi-arg ifunc selectors. - Fix a couple regressions in the assembly from v5 :/ - Use passed hwprobe pointer in memcpy ifunc selector. Changes in v5: - Do unaligned word access for final trailing bytes (Richard) Changes in v4: - Remove __USE_GNU (Florian) - __nonnull, __wur, __THROW, and __fortified_attr_access decorations (Florian) - change long to long int (Florian) - Fix comment formatting (Florian) - Update backup kernel header content copy. - Fix function declaration formatting (Florian) - Changed export versions to 2.38 - Fixed comment style (Florian) Changes in v3: - Update argument types to match v4 kernel interface - Add the "return" to the vsyscall - Fix up vdso arg types to match kernel v4 version - Remove ifdef around INLINE_VSYSCALL (Adhemerval) - Word align dest for large memcpy()s. - Add tags - Remove spurious blank line from sysdeps/riscv/memcpy.c Changes in v2: - hwprobe.h: Use __has_include and duplicate Linux content to make compilation work when Linux headers are absent (Adhemerval) - hwprobe.h: Put declaration under __USE_GNU (Adhemerval) - Use INLINE_SYSCALL_CALL (Adhemerval) - Update versions - Update UNALIGNED_MASK to match kernel v3 series. - Add vDSO interface - Used _MASK instead of _FAST value itself. Evan Green (7): riscv: Add Linux hwprobe syscall support linux: Introduce INTERNAL_VSYSCALL riscv: Add hwprobe vdso call support riscv: Add __riscv_hwprobe pointer to ifunc calls riscv: Enable multi-arg ifunc resolvers riscv: Add ifunc helper method to hwprobe.h riscv: Add and use alignment-ignorant memcpy include/libc-symbols.h | 28 ++-- sysdeps/riscv/dl-irel.h | 9 +- sysdeps/riscv/memcopy.h | 26 ++++ sysdeps/riscv/memcpy.c | 63 ++++++++ sysdeps/riscv/memcpy_noalignment.S | 136 ++++++++++++++++++ sysdeps/riscv/riscv-ifunc.h | 27 ++++ sysdeps/unix/sysv/linux/dl-vdso-setup.c | 10 ++ sysdeps/unix/sysv/linux/dl-vdso-setup.h | 3 + sysdeps/unix/sysv/linux/riscv/Makefile | 21 ++- sysdeps/unix/sysv/linux/riscv/Versions | 3 + sysdeps/unix/sysv/linux/riscv/hwprobe.c | 36 +++++ .../unix/sysv/linux/riscv/memcpy-generic.c | 24 ++++ .../unix/sysv/linux/riscv/rv32/libc.abilist | 1 + .../unix/sysv/linux/riscv/rv64/libc.abilist | 1 + sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h | 113 +++++++++++++++ sysdeps/unix/sysv/linux/riscv/sysdep.h | 1 + sysdeps/unix/sysv/linux/sysdep-vdso.h | 19 +++ 17 files changed, 504 insertions(+), 17 deletions(-) create mode 100644 sysdeps/riscv/memcopy.h create mode 100644 sysdeps/riscv/memcpy.c create mode 100644 sysdeps/riscv/memcpy_noalignment.S create mode 100644 sysdeps/riscv/riscv-ifunc.h create mode 100644 sysdeps/unix/sysv/linux/riscv/hwprobe.c create mode 100644 sysdeps/unix/sysv/linux/riscv/memcpy-generic.c create mode 100644 sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h
Comments
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. 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. [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html
On Feb 14 2024, Adhemerval Zanella Netto wrote: > 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. That will also help resolving bug 31317.
On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> 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 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. > > 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. > > [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html 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 :) 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. -Evan
On Thu, Feb 15, 2024 at 7:49 AM Evan Green <evan@rivosinc.com> wrote: > > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > <adhemerval.zanella@linaro.org> 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 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. > > > > 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. > > > > [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > > 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 :) certainly on Android we looked at the amount of work that would require (and the likely slowdown to dynamic linking, which is already problematic for us, given that it's a large component of app launch time that our zygote trick can't magic away) and decided that we're unlikely to do it, even though in principle it's a nice idea. > 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. > > -Evan
On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > <adhemerval.zanella@linaro.org> 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 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. >> >> 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. >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > > 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@google.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. 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
On Thu, Feb 15, 2024 at 8:50 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > > On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > > <adhemerval.zanella@linaro.org> 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 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. > >> > >> 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. > >> > >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > > > > 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@google.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
On Thu, 15 Feb 2024 09:00:03 PST (-0800), enh@google.com wrote: > On Thu, Feb 15, 2024 at 8:50 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: >> >> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >> > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto >> > <adhemerval.zanella@linaro.org> 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 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. >> >> >> >> 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. >> >> >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >> > >> > 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@google.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. So you're already committed to that ABI? > (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
On 15 Feb 2024, at 16:50, Palmer Dabbelt <palmer@rivosinc.com> wrote: > On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >> On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto >> <adhemerval.zanella@linaro.org> 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 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. >>> >>> 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. >>> >>> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >> >> 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@google.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, Not binary compatibility, source compatibility. Yes, it’s part of that platform’s ABI, but it leaks into the source code by means of the resolver’s 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’s no going back (without ugly “ignore that magic -1 argument, it’s there for historical reasons” kinds of situations). Adopting the stronger guarantees provided by FreeBSD’s rtld is one way to achieve that, and seems the simplest to me, but I’m 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 “not our problem, deal with it, we’re the dominant OS”, 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. > > 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
On Thu, Feb 15, 2024 at 9:22 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > > On Thu, 15 Feb 2024 09:00:03 PST (-0800), enh@google.com wrote: > > On Thu, Feb 15, 2024 at 8:50 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: > >> > >> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > >> > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > >> > <adhemerval.zanella@linaro.org> 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 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. > >> >> > >> >> 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. > >> >> > >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > >> > > >> > 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@google.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. > > So you're already committed to that ABI? "pretty much" given glibc release cycles and Android release cycles... the current API addresses a real problem with current dynamic linkers, and -- though it would have been great to make a different decision 16 years ago -- between the already stated reasons and the potential for app compat issues (and a distaste for having the riscv64 linker behavior differ from the already-shipped architectures), i think we'll want something like 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
On Thu, Feb 15, 2024 at 9:42 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 15 Feb 2024, at 16:50, Palmer Dabbelt <palmer@rivosinc.com> wrote: > > On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: > >> On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto > >> <adhemerval.zanella@linaro.org> 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 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. > >>> > >>> 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. > >>> > >>> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html > >> > >> 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@google.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, > > 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’s part of that > platform’s ABI, but it leaks into the source code by means of the > resolver’s 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’s no going back (without ugly “ignore that magic -1 argument, > it’s there for historical reasons” kinds of situations). Adopting the > stronger guarantees provided by FreeBSD’s rtld is one way to achieve > that, and seems the simplest to me, but I’m 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 “not our problem, deal > with it, we’re the dominant OS”, 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 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. > > > > 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 > >
On Thu, 15 Feb 2024 10:45:10 PST (-0800), enh@google.com wrote: > On Thu, Feb 15, 2024 at 9:22 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: >> >> On Thu, 15 Feb 2024 09:00:03 PST (-0800), enh@google.com wrote: >> > On Thu, Feb 15, 2024 at 8:50 AM Palmer Dabbelt <palmer@rivosinc.com> wrote: >> >> >> >> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >> >> > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto >> >> > <adhemerval.zanella@linaro.org> 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 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. >> >> >> >> >> >> 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. >> >> >> >> >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >> >> > >> >> > 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@google.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. >> >> So you're already committed to that ABI? > > "pretty much" given glibc release cycles and Android release cycles... Ya, cool -- I was just curious, I figured it'd be something along those lines (we also talked a bit off list). > the current API addresses a real problem with current dynamic linkers, > and -- though it would have been great to make a different decision 16 > years ago -- between the already stated reasons and the potential for > app compat issues (and a distaste for having the riscv64 linker > behavior differ from the already-shipped architectures), i think we'll > want something like that... Ya, I'm generally in favor of making RISC-V as unsurprising as possible. Given how complex the IFUNC stuff is it seems like a recipe for disaster to have different rules around linker ordering or cross-object symbol resoltion for RISC-V. Maybe folks want to change that for all the ports, but that seems like a fairly complex project and I'm worried we'll miss another release waiting on it. As far as I can tell the downside here is just that we have an extra argument pointing to a hwprobe function, that doesn't seem so painful to just support forever. It's not like this possible change to the resolution rules would make calling via the pre-resolved function argument invalid, it'd just be unnecessary. Thus I'm generally in favor of merging this, so Acked-by: Palmer Dabbelt <palmer@rivosinc.com> though I'm cool holding off a bit on merging it, in case anyone thinks that's a bad idea. >> > (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
On 15 Feb 2024, at 18:52, enh <enh@google.com> wrote: > > On Thu, Feb 15, 2024 at 9:42 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: >> >> On 15 Feb 2024, at 16:50, Palmer Dabbelt <palmer@rivosinc.com> wrote: >>> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >>>> On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto >>>> <adhemerval.zanella@linaro.org> 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 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. >>>>> >>>>> 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. >>>>> >>>>> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >>>> >>>> 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@google.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, >> >> 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’s part of that >> platform’s ABI, but it leaks into the source code by means of the >> resolver’s 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’s no going back (without ugly “ignore that magic -1 argument, >> it’s there for historical reasons” kinds of situations). Adopting the >> stronger guarantees provided by FreeBSD’s rtld is one way to achieve >> that, and seems the simplest to me, but I’m 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 “not our problem, deal >> with it, we’re the dominant OS”, 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? Yes, nobody’s going to copy that, but that doesn’t mean it’s going to forever be the only interface that you could use. One function existing doesn’t 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’t cover all use cases, and doesn’t need to, so long as it can deal with the ones that IFUNCs typically care about, i.e. simple questions like “do I have V/Zb*/etc?”), 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’re 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’m trying to look at the bigger picture here rather than the very narrow view of “what’s the easiest path to being able to write an IFUNCed memcpy in glibc for Linux”. > 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’t mean we shouldn’t 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.) > > 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’s 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’t limited to, being cross-platform. Jess >> 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. >>> >>> 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
On Wed, 14 Feb 2024 07:24:01 PST (-0800), schwab@suse.de wrote: > On Feb 14 2024, Adhemerval Zanella Netto wrote: > >> 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. > > That will also help resolving bug 31317. Sorry I missed that, I just commented on the bug. I think this thread got stuck on some other stuff, so maybe let's talk over there?
On Thu, 15 Feb 2024 11:09:13 PST (-0800), jrtc27@jrtc27.com wrote: > On 15 Feb 2024, at 18:52, enh <enh@google.com> wrote: >> >> On Thu, Feb 15, 2024 at 9:42 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: >>> >>> On 15 Feb 2024, at 16:50, Palmer Dabbelt <palmer@rivosinc.com> wrote: >>>> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote: >>>>> On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto >>>>> <adhemerval.zanella@linaro.org> 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 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. >>>>>> >>>>>> 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. >>>>>> >>>>>> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html >>>>> >>>>> 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@google.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, >>> >>> 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’s part of that >>> platform’s ABI, but it leaks into the source code by means of the >>> resolver’s 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’s no going back (without ugly “ignore that magic -1 argument, >>> it’s there for historical reasons” kinds of situations). Adopting the >>> stronger guarantees provided by FreeBSD’s rtld is one way to achieve >>> that, and seems the simplest to me, but I’m 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 “not our problem, deal >>> with it, we’re the dominant OS”, 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? > > Yes, nobody’s going to copy that, but that doesn’t mean it’s going to Why not? It's about the simplest interface that's extensible, essentially just a list of key-value pairs and some scaffolding to get them past a protection domain. > forever be the only interface that you could use. One function existing > doesn’t 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’t cover all use cases, and doesn’t need to, so long as > it can deal with the ones that IFUNCs typically care about, i.e. simple > questions like “do I have V/Zb*/etc?”), 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’re 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’m trying to look at the > bigger picture here rather than the very narrow view of “what’s the > easiest path to being able to write an IFUNCed memcpy in glibc for > Linux”. I think this is just going around in circles, it's basically the same discussion we had when adding hwprobe to Linux. We have a real concrete solution to real concrete problems, progress has been blocked for years without any concrete proposal aside from just doing something different. So like I said in some other thread, I'm inclined to just merge this. There's some feedback from Florian that looks pretty easy to resolve, and looks like Evan should have a new version soon. >> 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’t mean we shouldn’t 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? We have already defacto forked from the psABI pretty much everywhere due to all the unresolved issues, we just try to keep things compatible in practice -- or at least where we can, some of it just gets ignored. >> (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_). > > Well, it’s 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’t limited to, being > cross-platform. I guess it's kind of hard to evaluate hypothetical interface proposals, but it's not clear how merging this prevents a new interface from being added. Unless I'm missing something we've already got a NULL at the end of the argument list, so we should be safe to extend it. If users of this new interface can also call hwprobe then we'll need to maintain it forever, having an argument seems like a pretty straight-forward solution. > Jess > >>> 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. >>>> >>>> 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