From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) by sourceware.org (Postfix) with ESMTPS id 00E003858280 for ; Fri, 7 Jul 2023 22:11:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 00E003858280 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-4fb8574a3a1so3736788e87.1 for ; Fri, 07 Jul 2023 15:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1688767866; x=1691359866; 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=CYpsQUmN8CSAfbn2xQpZaFphGndFIjGGDtu/vgwW8os=; b=iPfRriVSmjlcvKGgEHrDvYqXzSWKtuAz7wYTndOHIhhzb7If2sW/Nij0GOjsO7rZNx PpSxG2FjtWZeCZqNEzpeSR7uIsHfrJ0tMFAF4VeDrZR8KoVpxFHn81Koh+46n2vSPSFm vN3fPnaBuB+3GBpfOLjw79xva48Cfu5OmOsiE+8KVqbGHUF5u1FIbO5GivZq34BJ2T61 SP9gClL0IByWc5Kw+3JBjmu4vSAoQJE3lJBCIY6UDzrGzkyW89YJRODUwqeQFKcIFwsM Ba/P9C1LOrKUWCC4xpSAVcDOISro6MKNehGMkDwAbKyNiLscwNgt0GRZr0rOMwRL52Ak 7S8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688767866; x=1691359866; 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=CYpsQUmN8CSAfbn2xQpZaFphGndFIjGGDtu/vgwW8os=; b=XBTxy0phrowGTSoCTMDs/jISQCYO2xtoRen1cAZTAb+VunA7aB67CHdzSfbib9GtrI j87vjfLxyFVpG5ZVz/PARBl7pN/MtfRP3junGkCgjwdSnSCBP7IApxEj/PfVAyeqB7Vx KOCw135DWoPgBD8xNcmwB8l0iyU8ESlCVPsfZQx0nGsMkYaX/vm1tumipY/Xhxsjec3a aRfAcHnFDY0ej9NV+h53L3LhewHYt6FtjsTxYABifTmLEXUf0UVEwu4yn0w2q3lI0PgV Sw98HDhCWN1TF+bn+MbLdILLS3PBIIVJ0DuSWJI0pCg9tmK7uC7m5+lWrsqTc8mhd3pE R2ig== X-Gm-Message-State: ABy/qLYCLD67x/8ll9aRGg98H4IxSLqKK5BQBLskGCsMuo0JLiPRIgut ynmIbROhw6k5VyPd62KzHSLsNJ0f/joihGMGB6YSdA== X-Google-Smtp-Source: APBJJlFHLz++SerlnnhDwaz34Uj8mOVNTjoW0nJhTwqjSfBnrCY477TdsIINXdjKR9IpDV/1me/9V++2kMTDlOSn+8k= X-Received: by 2002:ac2:5f79:0:b0:4f4:b783:8556 with SMTP id c25-20020ac25f79000000b004f4b7838556mr4657386lfc.66.1688767866134; Fri, 07 Jul 2023 15:11:06 -0700 (PDT) MIME-Version: 1.0 References: <20230706192947.1566767-1-evan@rivosinc.com> <20230706192947.1566767-2-evan@rivosinc.com> <878rbsi1c4.fsf@oldenburg.str.redhat.com> In-Reply-To: <878rbsi1c4.fsf@oldenburg.str.redhat.com> From: Evan Green Date: Fri, 7 Jul 2023 15:10:30 -0700 Message-ID: Subject: Re: [PATCH v4 1/3] riscv: Add Linux hwprobe syscall support To: Florian Weimer Cc: libc-alpha@sourceware.org, palmer@rivosinc.com, slewis@rivosinc.com, vineetg@rivosinc.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.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 List-Id: On Fri, Jul 7, 2023 at 1:16=E2=80=AFAM Florian Weimer = wrote: > > * Evan Green: > > > Add awareness and a thin wrapper function around a new Linux system cal= l > > that allows callers to get architecture and microarchitecture > > information about the CPUs from the kernel. This can be used to > > do things like dynamically choose a memcpy implementation. > > I missed before that you intend this for use in IFUNC resolvers, or at > the very least I think I forgot to raise this caveat. > > RISC-V is not a HIDDEN_VAR_NEEDS_DYNAMIC_RELOC target, so this is not > completely impossible, but in general, extern function calls in IFUNC > resolvers tend to not work well. The issue is that the GOT pointer for > a function like __riscv_hwprobe may not have been set up when the > dynamic linker invokes the IFUNC resolver. There are several ways to > solve this. You could pass the function pointer to the IFUNC resolver > (which may require a marker symbol and GCC changes). Or you could a > hidden wrapper function to libc_nonshared.a that checks if the function > pointer to the libc implementation has been set up by a relocation and > uses that, and falls back to a direct system call otherwise. That makes sense, but then I'm confused about how it's been working in my testing. What experiment should I try to see this problem in action? An early constructor maybe? Could I alternatively convert the implementation of the external function into one that calls an internal helper, and then just call the internal helper from the ifunc resolver (oh, I've reinvented a protected symbol)? Or is that a violation of some rule? Are there any examples of that last suggestion I can refer to? Specifically the part about checking if the symbol has been relocated yet or not. -Evan