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

[Adhemerval Zanella Netto]

On 21/04/23 10:56, Sergey Bugaev wrote:
> 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?

Indeed dl-symbol-redir-ifunc.h does not allow redirect the symbol in 
this dynamic way. But you can't really accomplish it without either 
hacking the ABI or using an override scheme, as we do for loader
malloc (elf/dl-minimal.c) where the minimal malloc is replaced on
final relocation phase.

The memcpy/memset/memmove is tricky because since compiler is free to
auto-generate calls to it we need to redirect it on a more direct way
(as explicit inline asm alias).

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

For Linux, the redirection is only used on very specific TU that can't 
really work with ifunc, and it is used only during static process 
initialization (like dl-support.c).

The 56010b73e81e2 commit message describes what seems to be a really
wacky scenario: lib{mach,hurd}user.so is relocated *before* libc.so; 
but they still call the libc.so symbols (because which seems to be
the compiler generated memcpy call).  The __mig_memcpy solution 
might work, but it is *really* hacky; but at same time I don't really
have a solution for this Hurd mess...