[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: |
Adhemerval Zanella Netto |
Subject: |
Re: [VERY RFC PATCH 2/2] hurd: Make it possible to call memcpy very early |
Date: |
Fri, 21 Apr 2023 08:50:54 -0300 |
User-agent: |
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 |
On 21/04/23 06:27, Sergey Bugaev wrote:
> Hello,
>
> On Thu, Apr 20, 2023 at 11:38 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
>> Can't you use a similar strategy done by
>> 5355f9ca7b10183ce06e8a18003ba30f43774858 ?
>
> Do I understand it right that that is the moral equivalent of
>
> #define memcpy __memcpy_sse2_unaligned
>
> except that it works aat assembly level and so will catch implicit
> calls to memcpy that the compiler may insert?
Yes, that's the idea.
>
> Assuming for a second that we don't care about implicit memcpys (but
> we should) and only about the explicit one made by the MIG runtime, we
> could maybe even just do
>
> void *
> __mig_memcpy (void *dst, const void *src, vm_size_t len)
> {
> - return memcpy (dst, src, len);
> + return __memcpy_sse2_unaligned (dst, src, len);
> }
>
> but that (as well as your proposal) would make *all* calls to memcpy
> in this place go through the baseline version, even after the early
> startup is done. Whereas my proposal attempted to avoid that -- unless
> of course H.J. is right and this prevents the indirect relocation from
> replacing the function pointer later, in which case it's even worse
> because it would sabotage memcpy for the whole program and not just a
> couple of files.
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.
And I trying to make reason why you need __mig_memcpy indirection for
MIG.
- [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 <=
- 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, 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