public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Evan Green <evan@rivosinc.com>
Cc: libc-alpha@sourceware.org,  palmer@rivosinc.com,
	 slewis@rivosinc.com, vineetg@rivosinc.com
Subject: Re: [PATCH v4 1/3] riscv: Add Linux hwprobe syscall support
Date: Fri, 07 Jul 2023 10:15:55 +0200	[thread overview]
Message-ID: <878rbsi1c4.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20230706192947.1566767-2-evan@rivosinc.com> (Evan Green's message of "Thu, 6 Jul 2023 12:29:44 -0700")

* Evan Green:

> Add awareness and a thin wrapper function around a new Linux system call
> 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.

Thanks,
Florian


  reply	other threads:[~2023-07-07  8:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-06 19:29 [PATCH v4 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface Evan Green
2023-07-06 19:29 ` [PATCH v4 1/3] riscv: Add Linux hwprobe syscall support Evan Green
2023-07-07  8:15   ` Florian Weimer [this message]
2023-07-07 22:10     ` Evan Green
2023-07-10  9:17       ` Florian Weimer
2023-07-11 17:08         ` Evan Green
2023-07-06 19:29 ` [PATCH v4 2/3] riscv: Add hwprobe vdso call support Evan Green
2023-07-06 19:29 ` [PATCH v4 3/3] riscv: Add and use alignment-ignorant memcpy Evan Green
2023-07-07  9:22   ` Richard Henderson
2023-07-07 15:25     ` Jeff Law
2023-07-07 21:37       ` Evan Green
2023-07-07 22:15         ` Jeff Law
2023-07-08  2:16   ` Stefan O'Rear
2023-07-10 16:19     ` Evan Green
2023-07-12  5:22       ` Stefan O'Rear
2023-07-06 20:11 ` [PATCH v4 0/3] RISC-V: ifunced memcpy using new kernel hwprobe interface Palmer Dabbelt
2023-07-06 22:20   ` Jeff Law

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=878rbsi1c4.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=evan@rivosinc.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).