public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: enh <enh@google.com>
To: Palmer Dabbelt <palmer@rivosinc.com>
Cc: Evan Green <evan@rivosinc.com>,
	adhemerval.zanella@linaro.org,  libc-alpha@sourceware.org,
	Vineet Gupta <vineetg@rivosinc.com>,
	fweimer@redhat.com,  slewis@rivosinc.com, jrtc27@debian.org
Subject: Re: [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface
Date: Thu, 15 Feb 2024 10:45:10 -0800	[thread overview]
Message-ID: <CAJgzZoovrM2Vcqwui5BrgGJaAv3bKwTD19Z1=WjbhCBrTjOMMA@mail.gmail.com> (raw)
In-Reply-To: <mhng-30c88df4-7724-451d-a8e5-49d07cecb976@palmer-ri-x1c9>

On Thu, Feb 15, 2024 at 9:22 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
>
> On Thu, 15 Feb 2024 09:00:03 PST (-0800), enh@google.com wrote:
> > On Thu, Feb 15, 2024 at 8:50 AM Palmer Dabbelt <palmer@rivosinc.com> wrote:
> >>
> >> On Thu, 15 Feb 2024 07:48:03 PST (-0800), Evan Green wrote:
> >> > On Wed, Feb 14, 2024 at 10:16 AM Adhemerval Zanella Netto
> >> > <adhemerval.zanella@linaro.org> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 14/02/24 11:31, Evan Green wrote:
> >> >> >
> >> >> > This series illustrates the use of a recently accepted Linux syscall that
> >> >> > enumerates architectural information about the RISC-V cores the system
> >> >> > is running on. In this series we expose a small wrapper function around
> >> >> > the syscall. An ifunc selector for memcpy queries it to see if unaligned
> >> >> > access is "fast" on this hardware. If it is, it selects a newly provided
> >> >> > implementation of memcpy that doesn't work hard at aligning the src and
> >> >> > destination buffers.
> >> >> >
> >> >> > For applications and libraries outside of glibc that want to use
> >> >> > __riscv_hwprobe() in ifunc selectors, this series also sends a pointer
> >> >> > to the riscv_hwprobe() function in as the second argument to ifunc
> >> >> > selectors. A new inline convenience function can help application and
> >> >> > library callers to check for validity and quickly probe a single key.
> >> >>
> >> >> I still think we should address Jessica Clarke remarks for the ifunc ABI [1].
> >> >> I recall that Florian has tried to address the ifunc ordering and that
> >> >> Jessica proposed solutions was not fully sufficient to address all the
> >> >> ifunc corner cases.
> >> >>
> >> >> [1] https://sourceware.org/pipermail/libc-alpha/2024-January/154082.html
> >> >
> >> > I haven't invested the time yet in studying the resolver to understand
> >> > how feasible Jessica's suggestion is. I was sort of hoping Florian
> >> > would chime in with an "oh yeah let's do that" or "no, it doesn't
> >> > work". I suppose I still am :)
> >>
> >> The discussion's over here:
> >> https://inbox.sourceware.org/libc-alpha/20231017044641.pw2ccr6exvhtmhkk@google.com/
> >>
> >> I was inclined to just ignore it: Florian explained what's going on with
> >> the multiple libraries constraint, so we're kind of just going around in
> >> circles at that point.
> >>
> >> I'm also not sure the argument makes a whole lot of sense in the first
> >> place.  The core of the argument seems to be around binary compatibility
> >> with other kernels/libcs, but there's a ton of reasons why binaries
> >> aren't compatible between those systems.  So if glibc just has a more
> >> complex IFUNC resolving scheme and that ends up requiring the extra
> >> agrument, then users of glibc have to go deal with that -- other
> >> systems/libcs might make different decisions, but that's just how these
> >> things go.
> >
> > yeah, i struggle with the portability premise too. not least because
> > macOS/iOS (which is obviously the most common "other platform" for me
> > with my Android hat on) doesn't have ifuncs at all. that's quite a big
> > blocker to any dream of portability.
> >
> > as i've said before, in a survey of all the open source libraries that
> > go into Android, there are none that don't support macOS/iOS, and so
> > there are none that actually rely on ifuncs. ifunc usage is limited to
> > libc (which is why we libc maintainers get bikeshedded by stuff like
> > this) and compiler-generated FMV stuff. i'd argue that "real people"
> > (app developers) should probably be looking at the latter anyway, and
> > it's our job to make that work (which happens once^Wtwice, in llvm and
> > gcc).
> >
> > also, the fact that Android is doing what's proposed here (with the
> > extra argument) means there'd be _some_ incompatibility even if glibc
> > and FreeBSD didn't do that.
>
> So you're already committed to that ABI?

"pretty much" given glibc release cycles and Android release cycles...

the current API addresses a real problem with current dynamic linkers,
and -- though it would have been great to make a different decision 16
years ago -- between the already stated reasons and the potential for
app compat issues (and a distaste for having the riscv64 linker
behavior differ from the already-shipped architectures), i think we'll
want something like that...

> > (Android's only source incompatibility with glibc at the moment is the
> > lack of the single-probe helper inline, which i fear will encourage
> > _worse_ code, but suspect will actually be unused in practice anyway
> > for the same "ifuncs are 'assembler' for libc/toolchain, and
> > library/app developers doing stuff themselves will continue to use
> > regular function pointers like they do today" reasons.)
> >
> >> Looks like Maskray is proposing making glibc's IFUNC resolving.  That's
> >> a generic glibc decision and I don't really understand this stuff well
> >> enough to have much of an opinion -- sure maybe the multi-library IFUNC
> >> resolving is overkill, but aside from doing some similar grep of all the
> >> sources (or trying some builds and such) I'm not sure how to tell if
> >> we're safe breaking the ABI there.
> >>
> >> That said, we're not comitting to ABI stability until the release.  So
> >> if we decide to make a generic glibc change we can always go drop the
> >> argument, that should be easy.  Maybe we even just throw out a RFC patch
> >> to do it, unless I'm missing something the code is the easy part here
> >> (we're essentially just going back to one of the early versions, from
> >> before we knew about this resolving order complexity).
> >>
> >> > Alternatively, patches 1-3 of this series stand on their own. If the
> >> > ifunc aspect of this is gated on me doing a bunch of research, it
> >> > might at least make sense to land the first half now, to get Linux
> >> > users easy access to the __riscv_hwprobe() syscall and vDSO.
> >>
> >> I'm OK with that, too.
> >>
> >> >
> >> > -Evan

  reply	other threads:[~2024-02-15 18:45 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 14:31 Evan Green
2024-02-14 14:31 ` [PATCH v12 1/7] riscv: Add Linux hwprobe syscall support Evan Green
2024-02-14 14:31 ` [PATCH v12 2/7] linux: Introduce INTERNAL_VSYSCALL Evan Green
2024-02-16  7:44   ` Florian Weimer
2024-02-23 23:12     ` Evan Green
2024-02-23 23:29       ` Gabriel Ravier
2024-02-24  2:06         ` Richard Henderson
2024-02-24 11:40       ` Florian Weimer
2024-02-26 16:47         ` Evan Green
2024-02-26 17:07           ` Florian Weimer
2024-02-26 17:57             ` Evan Green
2024-02-14 14:31 ` [PATCH v12 3/7] riscv: Add hwprobe vdso call support Evan Green
2024-02-14 14:31 ` [PATCH v12 4/7] riscv: Add __riscv_hwprobe pointer to ifunc calls Evan Green
2024-02-14 14:31 ` [PATCH v12 5/7] riscv: Enable multi-arg ifunc resolvers Evan Green
2024-02-16  7:45   ` Florian Weimer
2024-02-14 14:31 ` [PATCH v12 6/7] riscv: Add ifunc helper method to hwprobe.h Evan Green
2024-02-14 14:31 ` [PATCH v12 7/7] riscv: Add and use alignment-ignorant memcpy Evan Green
2024-02-14 15:16 ` [PATCH v12 0/7] RISC-V: ifunced memcpy using new kernel hwprobe interface Adhemerval Zanella Netto
2024-02-14 15:24   ` Andreas Schwab
2024-02-22 18:44     ` Palmer Dabbelt
2024-02-15 15:48   ` Evan Green
2024-02-15 15:57     ` enh
2024-02-15 16:50     ` Palmer Dabbelt
2024-02-15 17:00       ` enh
2024-02-15 17:22         ` Palmer Dabbelt
2024-02-15 18:45           ` enh [this message]
2024-02-15 18:56             ` Palmer Dabbelt
2024-02-15 17:42       ` Jessica Clarke
2024-02-15 18:52         ` enh
2024-02-15 19:09           ` Jessica Clarke
2024-02-22 19:41             ` Palmer Dabbelt

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='CAJgzZoovrM2Vcqwui5BrgGJaAv3bKwTD19Z1=WjbhCBrTjOMMA@mail.gmail.com' \
    --to=enh@google.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=evan@rivosinc.com \
    --cc=fweimer@redhat.com \
    --cc=jrtc27@debian.org \
    --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).