(I was half-tempted to call this proposal "stop pretending linking on RISC is easy").

Architectures with fixed width instructions have the inherent issue that a 32-bit (or 64-bit!) displacement cannot be stuffed into a 32-bit instruction, so an address needs to be spread across several instructions, and in turn this requires a sequence of relocations, each updating a part of an instruction. This leads to relocations that are inherently processor specific.

The way the Go toolchain handles this currently is a bit wacky, IMO. We have processor-specific relocations such as R_ADDRARM64 that relocate a specific pair of instructions that load an address into a register, which leads to such nastiness as having to care about target endianness when relocating the instructions. (In addition we have the grottiness that the value being relocated is encded, along with the addend, to archreloc in r.Add, i.e. #10050, but that could be killed separately).

I think there would be a net reduction in headaches if cmd/internal/obj generated relocations that touched a single instruction, like an ELF linker does. I've implemented this for arm64 at mwhudson@d6c0d0f and I think this is a lot cleaner.

Intel doesn't have this problem nearly so much, because generally speaking you can just stuff an offset into the instruction stream, but I think handling the TLS relocations in archreloc would be cleaner.

Obviously this is only something for Go 1.6 but as I'm starting to look into porting -buildmode=shared to other architectures, I'd like to get agreement on the basic approach before I start building my house of cards on it.