ziglang
rethink `.got.zig`
follow-up on #20884
After #20884, we are no longer compatible with existing tooling as custom Zig relocs are emitted for RISC-V when using build-obj. In this specific case, we needed to create a relocation for statically accessing the GOT in a non-pcrel manner. However, there are still flaws in the .got.zig design, like the self-hosted backends need to create logic to handle whether a symbol is inside of a .got.zig or not.
Microsoft thought up a neat idea we could apply instead called a thunk table. It's used in link.exe and is probably the only functional incremental linking implementation. @kubkon and I would like to replace .got.zig with it one day since it plays nicer with other arches.
This came about after @Rexicon226 and I had a few back and forth discussions re handling of linker relocs on the backend side. Currently how this is handled can be somewhat (a lot?) confusing since the backend, at the Emit layer has to be aware of the fact that something like .got.zig actually exists. What if the backends didn't have to worry about this implementation detail at all? My idea here is to re-use what Microsoft has been doing for their incremental linker all along, and also what we do for range extenders for RISC (excluding riscv) architectures, namely jump/thunk tables that are embedded directly in the machine code section. With this we still point the symbol's references to the jump table and only rewrite the jump table's entry target address when it gets shifted in memory at the cost of more bytes (since a thunk would contain at least one instruction per target), however we now gain simpler to reason and write backends which I think is a good tradeoff. I want to take this idea for a spin after I am done with my current effort of refactoring resource ownership in the ELF linker.
I am marking this issue as an enhancement but it may very well be a dead end. We won't know until I (we) try I guess!