TLS relocations referencing section symbols

[Cary Coutant]

In the gABI Symbol Table section, under STT_TLS, it says:

"Symbols of type STT_TLS can be referenced by only special
thread-local storage relocations and thread-local storage relocations
can only reference symbols with type STT_TLS."

This statement would outlaw the reasonable technique of referring to a
.tdata or .tbss STT_SECTION symbol with an offset in lieu of a local
STT_TLS symbol belonging to that section. Some linkers generate DTPMOD
relocations for a local TLS symbol by collapsing all references to
local TLS symbols to the TLS section symbol. There is also precedent
for using this type of reference at compile time; see binutils PR
16773, for example:

https://sourceware.org/bugzilla/show_bug.cgi?id=16773

The validity of this has been challenged in binutils PR 17699:

https://sourceware.org/bugzilla/show_bug.cgi?id=17699

and the statement above is the only place I can find in any ABI
documentation that would render it invalid.

I'd like to propose amending this statement to the following:

"Symbols of type STT_TLS can be referenced only by special
thread-local storage relocations. Thread-local storage relocations can
reference only symbols of type STT_TLS, or symbols of type STT_SECTION
where the referenced section has the SHF_TLS flag."

As the architect of the PA-RISC and IA-64 TLS model that was then
adopted into the gABI, I can confirm that this was the intent from the
very beginning. The overly-restrictive wording is nothing but an
oversight, in my opinion.

-cary

[Suprateeka R Hegde]

On 24-Nov-2016 01:21 AM, Cary Coutant wrote:
> I'd like to propose amending this statement to the following:
>
> "Symbols of type STT_TLS can be referenced only by special
> thread-local storage relocations. Thread-local storage relocations can
> reference only symbols of type STT_TLS, or symbols of type STT_SECTION
> where the referenced section has the SHF_TLS flag."

That looks complete enough. I have just one thought:

Taking it to runtime, there might be dyn relocs offsetting into PT_TLS?
I remember reading that in Drepper's TLS paper.

On HP-UX/IA-64, we have __thread_specific_seg, and thats of type
STT_SECTION pointing to (with a section index same as) .tbss/.tdata.

I was just thinking if there is an implementation that uses STT_NOTYPE
to create a symbol to point to such TLS segments and dyn-reloca are
based on that? So do we want to include STT_NOTYPE? Or does that become
too generic?

--
Supra

>
> As the architect of the PA-RISC and IA-64 TLS model that was then
> adopted into the gABI, I can confirm that this was the intent from the
> very beginning. The overly-restrictive wording is nothing but an
> oversight, in my opinion.
>
> -cary
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[Alan Modra]

On Sun, Nov 27, 2016 at 10:40:02PM +0530, Suprateeka R Hegde wrote:
> On 24-Nov-2016 01:21 AM, Cary Coutant wrote:
> >I'd like to propose amending this statement to the following:
> >
> >"Symbols of type STT_TLS can be referenced only by special
> >thread-local storage relocations. Thread-local storage relocations can
> >reference only symbols of type STT_TLS, or symbols of type STT_SECTION
> >where the referenced section has the SHF_TLS flag."
>
> That looks complete enough. I have just one thought:

I hesitate to mention it because covering everything leads to
unwieldy specs, but there is one special relocation case: Relocations
used to mark instructions for optimization. It is reasonable to allow
these relocations to reference TLS symbols *or* non-TLS symbols.

For example, the PowerPC64 TLS ABI specifies two variants for
small-model __tls_get_addr calls, one for the usual ELF linker managed
GOT, and one for the PowerOpen compiler managed GOT (or TOC). Notice
how the R_PPC64_TLSGD marker reloc that ties the argument setup insn
with the __tls_get_addr call takes a TLS symbol in the ELF GOT code:

Code sequence Reloc Sym
addi 3,2,x@got@tlsgd R_PPC64_GOT_TLSGD16 x
bl __tls_get_addr(x@tlsgd) R_PPC64_TLSGD x
R_PPC64_REL24 __tls_get_addr
nop
..
GOT[n] R_PPC64_DTPMOD64 x
GOT[n+1] R_PPC64_DTPREL64 x

and a non-TLS symbol in the PowerOpec TOC code:

Code sequence Reloc Sym
addi 3,2,.LC0@toc R_PPC64_TOC16 .LC0
bl __tls_get_addr(.LC0@tlsgd) R_PPC64_TLSGD .LC0
R_PPC64_REL24 __tls_get_addr
nop
..
.section .toc,"aw"
.LC0:
.quad x@dtpmod R_PPC64_DTPMOD64 x
.quad x@dtprel R_PPC64_DTPREL64 x

> Taking it to runtime, there might be dyn relocs offsetting into PT_TLS? I
> remember reading that in Drepper's TLS paper.
>
> On HP-UX/IA-64, we have __thread_specific_seg, and thats of type STT_SECTION
> pointing to (with a section index same as) .tbss/.tdata.
>
> I was just thinking if there is an implementation that uses STT_NOTYPE to
> create a symbol to point to such TLS segments and dyn-reloca are based on
> that? So do we want to include STT_NOTYPE? Or does that become too generic?

I don't see why any such symbol can't be created as STT_TLS. If
STT_NOTYPE is allowed then linker relocation validity checks are
weakened.

>
> --
> Supra
>
> >
> >As the architect of the PA-RISC and IA-64 TLS model that was then
> >adopted into the gABI, I can confirm that this was the intent from the
> >very beginning. The overly-restrictive wording is nothing but an
> >oversight, in my opinion.
> >
> >-cary
> >

--

Alan Modra
Australia Development Lab, IBM

[Suprateeka R Hegde]

On 28-Nov-2016 06:15 AM, Alan Modra wrote:
> On Sun, Nov 27, 2016 at 10:40:02PM +0530, Suprateeka R Hegde wrote:
>> On 24-Nov-2016 01:21 AM, Cary Coutant wrote:
>>> I'd like to propose amending this statement to the following:
>>>
>>> "Symbols of type STT_TLS can be referenced only by special
>>> thread-local storage relocations. Thread-local storage relocations can
>>> reference only symbols of type STT_TLS, or symbols of type STT_SECTION
>>> where the referenced section has the SHF_TLS flag."
>>
>> That looks complete enough. I have just one thought:
>
> I hesitate to mention it because covering everything leads to
> unwieldy specs, but there is one special relocation case: Relocations
> used to mark instructions for optimization. It is reasonable to allow
> these relocations to reference TLS symbols *or* non-TLS symbols.

That looks necessary and reasonable. I was wondering how do we state
that in the gABI.

Also, is this marker type reloc generic enough to be made into gABI?

>> Taking it to runtime, there might be dyn relocs offsetting into PT_TLS? I
>> remember reading that in Drepper's TLS paper.
>>
>> On HP-UX/IA-64, we have __thread_specific_seg, and thats of type STT_SECTION
>> pointing to (with a section index same as) .tbss/.tdata.
>>
>> I was just thinking if there is an implementation that uses STT_NOTYPE to
>> create a symbol to point to such TLS segments and dyn-reloca are based on
>> that? So do we want to include STT_NOTYPE? Or does that become too generic?
>
> I don't see why any such symbol can't be created as STT_TLS.

May be because there is no "storage" (TLS) as such associated with that
symbol. Its an absolute symbol. And usually toolchain inserted (not user
defined).

But yes, making it STT_TLS is no harm, (based on its functionality/usage)

If
> STT_NOTYPE is allowed then linker relocation validity checks are
> weakened.

Agree, Relocation as well as resolution. I had a thread:
https://goo.gl/HvC1yx

And later came to know that there is a bugzilla entry also:
https://goo.gl/QSQfTB

--
Supra

[Ali Bahrami]

We (Solaris) see no issue with this proposed change in
wording --- it makes sense, and especially given your original
intent, the ABI should be changed. It's nice to be in the position
of actually knowing what the original design intended. :-)

It doesn't look like our link-editor allows this case (we're like
gold --- implemented it from the spec), but we'll change it
as necessary.

We'll also update our Linker and Libraries Guild to match.
Could you please post back here when the final wording is
set, so that we can stay in sync?

A related question: Do we have a maintainer for the gABI
now? I haven't heard of one since John Wolfe left Xinous.
I've been sitting on something else that needs updating in
the gABI because I didn't think there was anyone to act
on it.

Thanks.

- Ali

[Cary Coutant]

> I hesitate to mention it because covering everything leads to
> unwieldy specs, but there is one special relocation case: Relocations
> used to mark instructions for optimization. It is reasonable to allow
> these relocations to reference TLS symbols *or* non-TLS symbols.
>
> For example, the PowerPC64 TLS ABI specifies two variants for
> small-model __tls_get_addr calls, one for the usual ELF linker managed
> GOT, and one for the PowerOpen compiler managed GOT (or TOC).

Alan's comment got me wondering where we define a "thread-local
storage relocation" -- the gABI doesn't say anything else about that.
And that led me wondering why we should even have this restriction in
the gABI at all. Shouldn't any restrictions on which symbol types can
be referenced by any particular relocation be left up to the psABI?

If others agree, maybe we should just amend the proposal to simply
remove that statement altogether, and insert the revised wording,
tailored as needed for each architecture, in the individual psABI
documents.

-cary

[Suprateeka R Hegde]

On 29-Nov-2016 02:52 AM, Cary Coutant wrote:

> If others agree, maybe we should just amend the proposal to simply
> remove that statement altogether, and insert the revised wording,
> tailored as needed for each architecture, in the individual psABI
> documents.

Agree. At least (on HP-UX) I do not see any conflicts with this.

--
Supra