Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 21/04/23 09:38, Sergey Bugaev wrote:
> 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.

That's the whole idea of dl-symbol-redir-ifunc.h, since it is explicit
enable by TU.

> 
>> 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

This seems essentially the very issue dl-symbol-redir-ifunc.h aims to fix.