From: Samuel Thibault <samuel.thibault@gnu.org>
To: Sergey Bugaev <bugaevc@gmail.com>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>,
"H.J. Lu" <hjl.tools@gmail.com>,
libc-alpha@sourceware.org, bug-hurd@gnu.org,
Luca <luca@orpolo.org>
Subject: Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early
Date: Sat, 22 Apr 2023 13:59:21 +0200 [thread overview]
Message-ID: <20230422115921.24upng76tpj2ymb3@begin> (raw)
In-Reply-To: <CAN9u=Hc5fCydr=9rAG7C0dSOms6_OJxr3VZ7hhGHfG3HOjRFQw@mail.gmail.com>
Sergey Bugaev, le ven. 21 avril 2023 16:56:57 +0300, a ecrit:
> 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?
Perhaps we can generate "init" variants of the RPCs that we need at
initialization, that are made to use the base memcpy implementation, and
only use them in the init code?
Samuel
next prev parent reply other threads:[~2023-04-22 11:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-20 18:42 [PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead Sergey Bugaev
2023-04-20 18:42 ` [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early Sergey Bugaev
2023-04-20 20:25 ` H.J. Lu
2023-04-20 20:38 ` Adhemerval Zanella Netto
2023-04-21 9:27 ` Sergey Bugaev
2023-04-21 11:50 ` Adhemerval Zanella Netto
2023-04-21 12:38 ` Sergey Bugaev
2023-04-21 12:58 ` Adhemerval Zanella Netto
2023-04-21 13:56 ` Sergey Bugaev
2023-04-21 14:28 ` Adhemerval Zanella Netto
2023-04-22 11:59 ` Samuel Thibault [this message]
2023-04-22 12:18 ` Sergey Bugaev
2023-04-22 16:20 ` Samuel Thibault
2023-04-22 17:04 ` Sergey Bugaev
2023-04-21 11:51 ` Sergey Bugaev
2023-04-21 1:02 ` [PATCH 1/2] hurd: Don't migrate reply port into __init1_tcbhead Samuel Thibault
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=20230422115921.24upng76tpj2ymb3@begin \
--to=samuel.thibault@gnu.org \
--cc=adhemerval.zanella@linaro.org \
--cc=bug-hurd@gnu.org \
--cc=bugaevc@gmail.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=luca@orpolo.org \
/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).