[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very earl
From: |
Sergey Bugaev |
Subject: |
Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early |
Date: |
Fri, 21 Apr 2023 16:56:57 +0300 |
On Fri, Apr 21, 2023 at 3:58 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
> > Yes, sure, I wasn't really suggesting we do that change. My point is,
> > I would like to make the same memcpy callsites both work during early
> > startup and start calling the more efficient implementation once early
> > startup is done -- if that's possible.
>
> That's the whole idea of dl-symbol-redir-ifunc.h, since it is explicit
> enable by TU.
Then I must be misunderstanding how dl-symbol-redir-ifunc.h works
(please explain!),
because I don't see how it would achieve that. Doesn't it change all
memcpy calls in the current translation unit (.c file) to always call
the baseline memcpy -- not only during startup, but even after the
startup has been completed?
To be clear, this is about memcpy calls made *during* very early
startup, yes, but not *in* some special startup-only code (like
init-first.c and hurdstartup.c for instance): that startup-specific
code calls into the fairly generic code (mig_memcpy.c and the various
MIG-generated RPC routines) that is used both during this very early
startup and then much later during the normal runtime, and *that's*
what calls memcpy. I'd like for memcpy calls in that generic code to
both work during early startup and use the efficient memcpy
implementation later. If dl-symbol-redir-ifunc.h can achieve that,
please help me understand how.
Sergey
- [PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead, Sergey Bugaev, 2023/04/20
- [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/20
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, H.J. Lu, 2023/04/20
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Adhemerval Zanella Netto, 2023/04/20
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/21
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Adhemerval Zanella Netto, 2023/04/21
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/21
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Adhemerval Zanella Netto, 2023/04/21
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early,
Sergey Bugaev <=
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Adhemerval Zanella Netto, 2023/04/21
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Samuel Thibault, 2023/04/22
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/22
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Samuel Thibault, 2023/04/22
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/22
- Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early, Sergey Bugaev, 2023/04/21
Re: [PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead, Samuel Thibault, 2023/04/20