[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 15:38:35 +0300 |
On Fri, Apr 21, 2023 at 2:50 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
> It might work if you don't care about a different architecture than x86,
> and that's why I added the alias (so each architecture is free to name
> its ifunc variant). And the patch was exactly to handle the implicit
> created mem* call from compiler, so I think you should take it in
> consideration.
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.
> And I trying to make reason why you need __mig_memcpy indirection for
> MIG.
See commit 56010b73e81e2cb1082e418699f98353598fe671 (as pointed out by
Samuel yesterday), which references [0]. But that's only relevant for
SHARED; for static we could avoid that redirection and call memcpy
directly indeed.
[0]: https://sourceware.org/pipermail/libc-alpha/2020-November/119575.html
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 <=
- 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, 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