cmd/link, runtime: properly handle TLS on linux/arm64 #10560
Comments
|
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. |
|
Only supporting assembly file is fine.
The problem is that some systems don't support TLS relocations, so the
symbol actually refers to a real variable that contains the TLS offset.
The existing special cases are for this. If the runtime.tlsg symbol always
means TLS relocation, then there shouldn't be much confusion.
|
|
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). |
|
Darwin/arm and Darwin/arm64 don't use .tbss for main executables. When
external linking,
although I think Mach-O does support TLS with clang, we don't generate them
as that's
too complicated. Instead, we use the same the trick that other Darwin ports
uses (guess the
TLS offset by bruteforcing the TLS slot for a pthread_setspecific key, or
vice versa).
Android/arm is different, we don't use .tbss either, but I don't fully
understand Android/ARM
to give a definite answer. (That's the reason my previous clean up attempt
broke Android/ARM.)
|
|
My original proposal is to make assembly file the single point of truth
(whether runtime.tlsg
is a variable or a placeholder for TLS relocation).
If tlsg is a variable, then all the references will use a load, whereas if
it's a placeholder for
TLS relocation, all the references will be taking the address.
This makes sense at the cmd/internal/obj level, but not at the linker
level. But I imagine
liblink should produce different internal relocation for those two cases
and the linker
shouldn't care.
|
|
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). |
|
I believe it's too late for this to go into Go 1.5. |
rsc
changed the title
|
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) |
Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
|
CL https://golang.org/cl/13991 mentions this issue. |
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
This uses the ELF ABI name for the relocation, as proposed in golang#11374. Fixes golang#10560 Change-Id: Iedffd9c236c4fbb386c3afc52c5a1457f96ef122
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.
The text was updated successfully, but these errors were encountered: