Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit: > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault <[email protected]> > wrote: > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy. > > > > > > Interesting; but that one's dealing with the SHARED case, isn't it? > > > > Yes but I guess it fixed the static case too? > > For the shared case, yes, lib*user will now reference > __mig_memcpy from libc.so, and that one needs a simple relocation > without ifunc.
Ah, I missed the part that said that __mig_memcpy just calls the (ifunc-) memcpy. I guess I shouldn't be replying when I don't actually have time to check all ins and outs of what I'm talking about :) > > > > > VM_MAX_USER_ADDRESS, which is defined to VM_MAX_ADDRESS, which is then > > > > > defined to 0xc0000000, same as on i386. That's of course too small. > > > > > Can we bump this substantially? > > > > > > > > Of course ! > > > > > > Let me actually try doing #define VM_MAX_ADDRESS KENEL_MAP_BASE... > > > > It doesn't need to be that high :) > > > > And actually it probably cannot: IIRC not all bits can be used in amd64 > > virtual addresses anyway. > > Yes, but apparently it still works for the kernel? Or is that some > other kind of address? IIRC the last really-usable bit of the virtual address is just replicated (to 0 for user and to 1 for kernel). > What would be a correct value then, 1 << 48? I don't know by heart, but something like that yes. Samuel
