providing __tls_get_addr on s390?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

providing __tls_get_addr on s390?

Aurelien Jarno
Dear all,

I have noticed that GCC recently started to use the
__tls_get_addr_internal symbol on s390 [1]. This is probably a bad
idea to use an internal libc symbol outside of the libc as it can be
modified or removed at anytime.

That said, I also noticed that s390 is (one of the) only architectures
which doesn't provide __tls_get_addr. Is there a reason for that? Is it
something that we should fix?

Thanks,
Aurelien

[1] https://gcc.gnu.org/viewcvs/gcc/trunk/libphobos/libdruntime/gcc/sections/elf_shared.d?r1=270522&r2=270523

--
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[hidden email]                 http://www.aurel32.net
Reply | Threaded
Open this post in threaded view
|

Re: providing __tls_get_addr on s390?

Carlos O'Donell-6
On 8/31/19 10:10 AM, Aurelien Jarno wrote:

> Dear all,
>
> I have noticed that GCC recently started to use the
> __tls_get_addr_internal symbol on s390 [1]. This is probably a bad
> idea to use an internal libc symbol outside of the libc as it can be
> modified or removed at anytime.
>
> That said, I also noticed that s390 is (one of the) only architectures
> which doesn't provide __tls_get_addr. Is there a reason for that? Is it
> something that we should fix?

Stefan,

Is there any reason s390 doesn't implement __tls_get_addr like other arches?
It's always easier if all the machines support the same generic infrastructure.
The lack of __tls_get_addr on s390 forces the D language runtime to have
Z Series specific code to handle TLS calculations :-(

Aurelien,

The D-language runtime encodes a ton of TLS-specific implementation details
and one of them is accessing TLS details.

This can be seen as a failing of glibc to provide a generic low-level TLS
interface for language runtimes. There aren't enough details spelled out
to make it easy to provide TLS details to the runtime.

Either way, *no* language runtime should be using GLIBC_PRIVATE symbols.
Could you please file a bug for that? If they need access they should do
so through the appropriate API e.g. __tls_get_addr which is a standard
API with specified semantics.

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: providing __tls_get_addr on s390?

Aurelien Jarno
On 2019-08-31 10:28, Carlos O'Donell wrote:

> On 8/31/19 10:10 AM, Aurelien Jarno wrote:
> > Dear all,
> >
> > I have noticed that GCC recently started to use the
> > __tls_get_addr_internal symbol on s390 [1]. This is probably a bad
> > idea to use an internal libc symbol outside of the libc as it can be
> > modified or removed at anytime.
> >
> > That said, I also noticed that s390 is (one of the) only architectures
> > which doesn't provide __tls_get_addr. Is there a reason for that? Is it
> > something that we should fix?
>
> Stefan,
>
> Is there any reason s390 doesn't implement __tls_get_addr like other arches?
> It's always easier if all the machines support the same generic infrastructure.
> The lack of __tls_get_addr on s390 forces the D language runtime to have
> Z Series specific code to handle TLS calculations :-(
>
> Aurelien,
>
> The D-language runtime encodes a ton of TLS-specific implementation details
> and one of them is accessing TLS details.
>
> This can be seen as a failing of glibc to provide a generic low-level TLS
> interface for language runtimes. There aren't enough details spelled out
> to make it easy to provide TLS details to the runtime.
>
> Either way, *no* language runtime should be using GLIBC_PRIVATE symbols.
> Could you please file a bug for that? If they need access they should do
> so through the appropriate API e.g. __tls_get_addr which is a standard
> API with specified semantics.

I have just submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
Please feel free to add more details.

--
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[hidden email]                 http://www.aurel32.net
Reply | Threaded
Open this post in threaded view
|

Re: providing __tls_get_addr on s390?

Stefan Liebler-2
In reply to this post by Carlos O'Donell-6
On 8/31/19 4:28 PM, Carlos O'Donell wrote:

> On 8/31/19 10:10 AM, Aurelien Jarno wrote:
>> Dear all,
>>
>> I have noticed that GCC recently started to use the
>> __tls_get_addr_internal symbol on s390 [1]. This is probably a bad
>> idea to use an internal libc symbol outside of the libc as it can be
>> modified or removed at anytime.
>>
>> That said, I also noticed that s390 is (one of the) only architectures
>> which doesn't provide __tls_get_addr. Is there a reason for that? Is it
>> something that we should fix?
>
> Stefan,
>
> Is there any reason s390 doesn't implement __tls_get_addr like other arches?
> It's always easier if all the machines support the same generic infrastructure.
> The lack of __tls_get_addr on s390 forces the D language runtime to have
> Z Series specific code to handle TLS calculations :-(
>
According to the s390 specific "ELF Handling for Thread-Local-Storage"
parts:
The s390 ABI is defined to use the __tls_get_offset function instead of
the __tls_get_addr function used in other ABIs. The prototype is:
unsigned long int __tls_get_offset (unsigned long int offset);

The function has a second, hidden parameter. The caller needs to set up
the GOT register %r12 to contain the address of the global offset table
of the caller’s module. The offset parameter, when added to the value of
the GOT register, yields the address of a tls_index structure located in
the caller’s global offset table.

The return value of __tls_get_offset is an offset to the thread pointer.
To get the address of the requested variable the thread pointer needs to
be added to the return value. The use of __tls_get_offset might seem
more complicated than the standard __tls_get_addr but for s390 the use
of tls get offset allows for better code sequences.


The D-language runtime should be fixed and use __tls_get_offset instead
of __tls_get_addr_internal@GLIBC_PRIVATE on s390x/s390.
__tls_get_offset internally computes the address of the tls_index struct
and then calls the not exported __tls_get_addr function.
But as __tls_get_offset assumes that the tls_index struct is located in
the GOT of the caller, it just adds r12 (=GOT-pointer) to the provided
offset in order to get the address to tls_index struct.

As Florian Weimer has already mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628#c6 the offset could
be prepared.
Usually r12 is setup by the compiler for cross-module calls. It is a
call-saved register and is not modified by the PLT code.


> Aurelien,
>
> The D-language runtime encodes a ton of TLS-specific implementation details
> and one of them is accessing TLS details.
>
> This can be seen as a failing of glibc to provide a generic low-level TLS
> interface for language runtimes. There aren't enough details spelled out
> to make it easy to provide TLS details to the runtime.
>
> Either way, *no* language runtime should be using GLIBC_PRIVATE symbols.
> Could you please file a bug for that? If they need access they should do
> so through the appropriate API e.g. __tls_get_addr which is a standard
> API with specified semantics.
>

Reply | Threaded
Open this post in threaded view
|

Re: providing __tls_get_addr on s390?

Carlos O'Donell-6
On 9/2/19 8:24 AM, Stefan Liebler wrote:

> The D-language runtime should be fixed and use __tls_get_offset
> instead of __tls_get_addr_internal@GLIBC_PRIVATE on s390x/s390.
> __tls_get_offset internally computes the address of the tls_index
> struct and then calls the not exported __tls_get_addr function. But
> as __tls_get_offset assumes that the tls_index struct is located in
> the GOT of the caller, it just adds r12 (=GOT-pointer) to the
> provided offset in order to get the address to tls_index struct.
>
> As Florian Weimer has already mentioned in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628#c6 the offset
> could be prepared. Usually r12 is setup by the compiler for
> cross-module calls. It is a call-saved register and is not modified
> by the PLT code.

Agreed, I think we're making progress here at removing the use of
GLIBC_PRIVATE from the D runtime which is great.

--
Cheers,
Carlos.