On Friday, 2 October 2026 at 15:49, Sergey Bugaev <[email protected]> wrote:
> > Also, I must mention that we compile with mcmodel=medany, and pretty > > much every dereference is made PC-relative, save for pointers stored in > > statically initialized file-scope/global variables. > > Yes, and those you can fairly simply relocate yourself (once you > switch to high memory). You might have seen my > 'apply_runtime_relocations', that's all there is to it. > Thanks. I will check that. > > We still assume > > a kernel placed at KERNEL_MAP_BASE though, our paging implementation > > makes use of that assumption currently. > > > > This raises another question, who is going to patch GOT entries if we > > enable -fPIC? How does your port do this -- do you patch dynamic > > relocations during early kernel init? > > I don't think you should have a GOT in the first place. GOT is useful > in two cases: > * referencing symbols from another DSO > * ifuncs > > But GNU Mach is its own statically linked "DSO", there is no other DSO > to reference, and we're not using ifuncs. So you should always be > doing PC-relative accesses, and there should not be any need for a > GOT. > You are actually right, I had a brain fart for a moment. With -fvisibilty=hidden, the compiler shouldn't really emit a GOT relocation in our case. I need to check to be certain though. I mean, even if it did, it's a dynamic relocation no different than the rest anyway, the shared fixup code would handle it. I do agree by principle we should not have GOT relocations in the kernel though, so I would be verifying they don't get accidentally emitted by the toolchain. > For AArch64, I had > > AM_CFLAGS += -static-pie -mcmodel=tiny -mgeneral-regs-only > gnumach_LINKFLAGS += -T '$(srcdir)'/aarch64/ldscript -static -pie > --no-dynamic-linker > > and that seems to have been enough. Alternatively, look into > -fvisibility=hidden. In manually written assembly code, make sure > you're not using any GOT-producing relocation types. > > Sergey > Thanks for the hints. Hakan
