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
next prev parent 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).