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

cmd/link, runtime: properly handle TLS on linux/arm64 #10560

Closed
minux opened this issue Apr 23, 2015 · 9 comments

Comments

Projects
None yet
4 participants
@minux
Copy link
Member

commented Apr 23, 2015

Right now the tls offset for g is hardcoded to be 0x10 in the
runtime. This works as long as Go program is the only thing
that uses TLS.

We should clean it up and use proper TLS relocations for
that.

Also, we should also investigate removing all the special
case in cmd/internal/obj/arm and linkers for runtime.tlsg for
ARM by introducing a unified framework for dealing with
runtime.tlsg (runtime.tls_g on arm64).

See also #10557.

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2015

I have wondered before if actual proper support in the toolchain for tls variables would be a next reduction in headaches. I think it would be OK if it was only supported for assembly files (or on the Prog/Addr level, which is more or less the same). If you only permitted moves to/from registers to the TLS var it would be pretty easy to mangle that to the right code in progedit for all arches I think.

@minux

This comment has been minimized.

Copy link
Member Author

commented Apr 24, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2015

Hmm. Which platforms are these? I don't understand how not supporting TLS relocations matters when not externally linking, but I guess we're talking about things like android where we technically make a shared object but one that behaves more like an executable on a traditional platform, and they basically implement the "initial exec" tls model by hand?

Still feels to me like cmd/internal/obj is the place to put the special casing -- the linker will need code for each special case of course, but deciding which special case to use should be done earlier IMHO (so I mean, codegen decides which reloc type to use and linker always interprets a given reloc type the same way on a given arch).

@minux

This comment has been minimized.

Copy link
Member Author

commented Apr 24, 2015

@minux

This comment has been minimized.

Copy link
Member Author

commented Apr 24, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Apr 24, 2015

I guess my concern is more the form (initial exec, local exec etc) of TLS rather than "TLS or not". So that leads to thinking that assembly decides var vs tls (via #ifdefs?) and then internal/obj decides how to handle the tls aspects if indeed we are doing tls (and emits relocation data that the linker can handle without further os/flag dependent conditionality).

@rsc

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2015

I believe it's too late for this to go into Go 1.5.

@rsc rsc modified the milestones: Unplanned, Go1.5 Jun 8, 2015

@rsc rsc changed the title cmd/7l, runtime: properly handle TLS on linux/arm64 cmd/link, runtime: properly handle TLS on linux/arm64 Jun 8, 2015

@mwhudson

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2015

Yes, I was hoping to make this more regular on all linux arches (not just linux/arm64) fairly early in 1.6 (I think I'll need to to make shared libraries work)

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

cmd/internal/obj,cmd/link,runtime: native-ish support for tls on arm64
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

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

@gopherbot gopherbot closed this in 72180c3 Oct 28, 2015

@golang golang locked and limited conversation to collaborators Nov 4, 2016

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.