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?
We must be talking past each other -- evidently it did not fix the static case, because I'm running into that issue now. On x86_64, that is; while on i386 it is working for the two reasons I listed. Moreover, I don't see how it could have changed anything for the static case. For the shared case, yes, lib*user will now reference __mig_memcpy from libc.so, and that one needs a simple relocation without ifunc. For the static case, it's all in the same binary; the only relocations left after static linking are the ifunc relocations, and the issue I'm having is different (and happens at an earlier stage). Or in other words: the issue I am/was running into was not that ifunc resolvers wouldn't work because of yet unrelocated _rtld_global_ro or some such, but that they aren't getting called in the first place. Instead we fetch some garbage pointers from the GOT *before* they are initialized by calling the ifunc resolvers, and jump there and eventually crash. (Or are they not garbage? It's suspicious that they really point back to the PLT.) > > > > 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? What would be a correct value then, 1 << 48? Sergey
