[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJgzZooxL0BV0KY3823yFZaqgsg2BKZqZGfgyxAaHLk1PZdi1w@mail.gmail.com>
Date: Fri, 28 Jul 2023 16:49:46 -0700
From: enh <enh@...gle.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: libc-coord@...ts.openwall.com
Subject: Re: risc-v hwprobe stuff
yeah, earlier this week palmer showed me
https://inbox.sourceware.org/libc-alpha/20230712193629.2880253-1-evan@rivosinc.com/
which puts it in <sys/hwprobe.h>, which was the main thing i wanted to
avoid us disagreeing on.
i've sent out a source-compatible bionic change:
https://android-review.googlesource.com/c/platform/bionic/+/2679530
there's nothing for vdso in that change because i have some other vdso
cleanup to do first anyway, but bionic currently mostly uses HWCAP for its
internal ifuncs (because arm64 is the primary architecture), and "inline
assembler syscalls to read a file" for arm32 (
https://android.googlesource.com/platform/bionic/+/refs/heads/main/libc/arch-arm/dynamic_function_dispatch.cpp)
because _that_ architecture was fragmented enough that "okay, you just
write in a file what routines you want to use for your device's SoC" was
the least impractical option. (for the rare bit of x86 optimization we
have, we just use __builtin_cpu_supports().)
we [here meaning "those of us interested in risc-v", not "those of us
maintaining c libraries" :-) ] will have to come up with something better
if we're to get function multi-versioning for risc-v like the existing
x86-64 stuff or the arm64 stuff Arm's been working on. tbh, i'm half
expecting that we end up reinventing the HWCAP wheel for the most common
extensions (*cough* V *cough*). given that V currently seems the most
likely thing anyone's going to want there, i'm pretty tempted to just pass
getauxval(HWCAP) to the riscv64 ifunc resolvers on Android anyway, so
anyone who wants them can have them. (though that's made quite a bit less
useful by the lack of a constant for V in the linux uapi header, even
though the _bit_ for V does get set. i could add the constant to bionic's
headers, obviously, but unless glibc does it too, that's probably only
useful to folks writing Android-only code, rather than all the people
writing code for "anything on top of a Linux kernel whose libc has
getauxval()"!)
On Fri, Jul 28, 2023 at 12:00 PM Florian Weimer <fw@...eb.enyo.de> wrote:
> > anyone else looking at adding a wrapper for the risc-v hwprobe stuff?
>
> We've had some discussions on the glibc libc-alpha list. One issue
> for glibc is that it's natural to use it in IFUNC resolvers, but you
> cannot call non-static, non-hidden functions from IFUNC resolvers
> reliably because of the relocation dependency. This means that a
> traditional system call wrapper in libc.so won't necessarily work for
> this. I don't think a decision has been reached yet. I expect the
> discussion to start again after the upcoming release.
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
