Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/link: handle code relocations more like an ELF linker #11374

Closed
mwhudson opened this issue Jun 24, 2015 · 6 comments

Comments

Projects
None yet
5 participants
@mwhudson
Copy link
Contributor

commented Jun 24, 2015

(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.

@mwhudson

This comment has been minimized.

Copy link
Contributor Author

commented Jun 24, 2015

Cc @iant @minux for thoughts.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 2, 2015

I think this merits an actual .md file. I'd really rather not read code to evaluate an idea.

@mwhudson

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2015

I guess, what would you like to see in the docs? I could imagine a series of examples of code, the instructions and relocations it is compiled into (for arm/arm64/ppc64 I guess) and then the implementations of those relocations in the linker. Anything else?

@gopherbot

This comment has been minimized.

Copy link

commented Aug 5, 2015

CL https://golang.org/cl/13170 mentions this issue.

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

mwhudson added a commit to mwhudson/proposal that referenced this issue Aug 7, 2015

proposal: handle code relocations more like a traditional linker
Updates golang/go#11374

Change-Id: I138f0f1515a0b32f437d2b624352a495ecca8a75

@mikioh mikioh added the Proposal label Aug 13, 2015

mwhudson added a commit to mwhudson/go that referenced this issue Aug 27, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

mwhudson added a commit to mwhudson/go that referenced this issue Aug 27, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

mwhudson added a commit to mwhudson/go that referenced this issue Aug 27, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
@gopherbot

This comment has been minimized.

Copy link

commented Aug 28, 2015

CL https://golang.org/cl/13991 mentions this issue.

mwhudson added a commit to mwhudson/go that referenced this issue Sep 1, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

mwhudson added a commit to mwhudson/go that referenced this issue Sep 2, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

mwhudson added a commit to mwhudson/go that referenced this issue Sep 8, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

mwhudson added a commit to mwhudson/go that referenced this issue Sep 11, 2015

cmd/internal/obj, cmd/link, runtime: native-ish support for tls on arm64
This uses the ELF ABI name for the relocation, as proposed in golang#11374.

Fixes golang#10560

Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122

@rsc rsc modified the milestones: Proposal, Unreleased Oct 24, 2015

@rsc rsc changed the title proposal: handle code relocations more like an ELF linker proposal: cmd/link: handle code relocations more like an ELF linker Oct 24, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2016

No longer planning to do anything here myself.

@mwhudson mwhudson closed this Apr 25, 2016

@golang golang locked and limited conversation to collaborators Apr 25, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.