public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Jessica Clarke <jrtc27@jrtc27.com>
To: Evan Green <evan@rivosinc.com>
Cc: libc-alpha@sourceware.org, slewis@rivosinc.com,
	Florian Weimer <fweimer@redhat.com>,
	vineetg@rivosinc.com, palmer@rivosinc.com
Subject: Re: [PATCH v8 3/6] riscv: Add __riscv_hwprobe pointer to ifunc calls
Date: Fri, 29 Sep 2023 19:21:58 +0100	[thread overview]
Message-ID: <ZRcVxhvfu/xdjBPG@Jessicas-MacBook-Pro> (raw)
In-Reply-To: <20230901235224.3304592-4-evan@rivosinc.com>

On Fri, Sep 01, 2023 at 04:52:21PM -0700, Evan Green wrote:
> The new __riscv_hwprobe() function is designed to be used by ifunc
> selector functions. This presents a challenge for applications and
> libraries, as ifunc selectors are invoked before all relocations have
> been performed, so an external call to __riscv_hwprobe() from an ifunc
> selector won't work. To address this, pass a pointer to the
> __riscv_hwprobe() vDSO function into ifunc selectors as the second
> argument (alongside dl_hwcap, which was already being passed).
> 
> Include a typedef as well for convenience, so that ifunc users don't
> have to go through contortions to call this routine. Users will need to
> remember to check the second argument for NULL, both to account for
> older glibcs that don't pass the function, and older kernels that don't
> have the vDSO pointer.

This makes the IFUNC interface Linux-specific, which seems gratuitous.
Being able to write portable IFUNC resolvers across Linux, BSDs and
other similar OSes is valuable, and this would preclude that. In FreeBSD
there are no issues with calling functions from IFUNC resolvers; we just
process all non-IRELATIVE relocations before IRELATIVE ones. It sounds
like glibc could benefit from the same; then you wouldn't have to hack
things up like this.

Alternatively we could have a standardised "what extensions do I have"
interface passed in the pointer instead, but the Linux's hwprobe (with
the Linux-defined IDs for every extension Linux chooses to support and
poor extensibility for vendors) is not and will never be that.

I urge you to not continue down the "who cares about portability" path.

Jess

> Signed-off-by: Evan Green <evan@rivosinc.com>
> 
> ---
> 
> (no changes since v7)
> 
> Changes in v7:
>  - Remove __THROW from function pointer type, as it creates warnings
>    together with __fortified_attr_access.
> 
>  sysdeps/riscv/dl-irel.h                     |  8 ++++----
>  sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h | 10 ++++++++++
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/sysdeps/riscv/dl-irel.h b/sysdeps/riscv/dl-irel.h
> index eaeec5467c..2147504458 100644
> --- a/sysdeps/riscv/dl-irel.h
> +++ b/sysdeps/riscv/dl-irel.h
> @@ -31,10 +31,10 @@ static inline ElfW(Addr)
>  __attribute ((always_inline))
>  elf_ifunc_invoke (ElfW(Addr) addr)
>  {
> -  /* The second argument is a void pointer to preserve the extension
> -     fexibility.  */
> -  return ((ElfW(Addr) (*) (uint64_t, void *)) (addr))
> -	 (GLRO(dl_hwcap), NULL);
> +  /* The third argument is a void pointer to preserve the extension
> +     flexibility.  */
> +  return ((ElfW(Addr) (*) (uint64_t, void *, void *)) (addr))
> +	 (GLRO(dl_hwcap), GLRO(dl_vdso_riscv_hwprobe), NULL);
>  }
>  
>  static inline void
> diff --git a/sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h b/sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h
> index aa189a4818..fd3be5a411 100644
> --- a/sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h
> +++ b/sysdeps/unix/sysv/linux/riscv/sys/hwprobe.h
> @@ -67,6 +67,16 @@ extern int __riscv_hwprobe (struct riscv_hwprobe *__pairs, size_t __pair_count,
>       __fortified_attr_access (__read_write__, 1, 2)
>       __fortified_attr_access (__read_only__, 4, 3);
>  
> +/* A pointer to the __riscv_hwprobe vDSO function is passed as the second
> +   argument to ifunc selector routines. Include a function pointer type for
> +   convenience in calling the function in those settings. */
> +typedef int (*__riscv_hwprobe_t) (struct riscv_hwprobe *__pairs, size_t __pair_count,
> +				  size_t __cpu_count, unsigned long int *__cpus,
> +				  unsigned int __flags)
> +     __nonnull ((1)) __wur
> +     __fortified_attr_access (__read_write__, 1, 2)
> +     __fortified_attr_access (__read_only__, 4, 3);
> +
>  __END_DECLS
>  
>  #endif /* sys/hwprobe.h */
> -- 
> 2.34.1
> 

  reply	other threads:[~2023-09-29 18:22 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01 23:52 [PATCH v8 0/6] RISC-V: ifunced memcpy using new kernel hwprobe interface Evan Green
2023-09-01 23:52 ` [PATCH v8 1/6] riscv: Add Linux hwprobe syscall support Evan Green
2023-09-01 23:52 ` [PATCH v8 2/6] riscv: Add hwprobe vdso call support Evan Green
2023-09-01 23:52 ` [PATCH v8 3/6] riscv: Add __riscv_hwprobe pointer to ifunc calls Evan Green
2023-09-29 18:21   ` Jessica Clarke [this message]
2023-09-29 19:40     ` Florian Weimer
2023-09-29 19:49       ` Jessica Clarke
2023-10-17  4:46       ` Fangrui Song
2023-09-01 23:52 ` [PATCH v8 4/6] riscv: Enable multi-arg ifunc resolvers Evan Green
2023-09-01 23:52 ` [PATCH v8 5/6] riscv: Add ifunc helper method to hwprobe.h Evan Green
2023-09-01 23:52 ` [PATCH v8 6/6] riscv: Add and use alignment-ignorant memcpy Evan Green
2023-09-25 10:28 ` [PATCH v8 0/6] RISC-V: ifunced memcpy using new kernel hwprobe interface Palmer Dabbelt
2023-09-26  2:24   ` enh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZRcVxhvfu/xdjBPG@Jessicas-MacBook-Pro \
    --to=jrtc27@jrtc27.com \
    --cc=evan@rivosinc.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=palmer@rivosinc.com \
    --cc=slewis@rivosinc.com \
    --cc=vineetg@rivosinc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).