Re: TLS redux

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 14 Jan 2014, Roland McGrath wrote:

> * Lazy allocation is an explicit feature of the TLS ABI, not an
>   incidental detail.  The wisdom of the feature can be debated, but
>   the compatibility requirements are clear.

I think of this as falling under "ABIs are ABIs for C and statements 
therein that contradict C semantics must be rejected".  (As in the bits of 
AAPCS regarding volatile bit-fields that contradict the C11/C++11 memory 
model, for example.)  C (both the GNU C specification of __thread, and C11 
_Thread_local) does not admit of TLS variables being any less reliable or 
signal-safe than variables of static storage duration.  Generally, if some 
functionality has no way defined to indicate an error - as is generally 
the case for language constructs, but also for library functions with no 
error return mechanism such as memcmp - it needs to succeed, in accordance 
with the specified semantics, unless the program has done something 
involving undefined behavior.

I don't object to backwards compatibility for existing binaries relying on 
lazy allocation (although I'm doubtful such binaries are actually in use), 
but I start from an assumption that the default for new binaries must be 
to implement C semantics, which means detecting errors when error returns 
are possible (at dlopen and pthread_create time, in this case) rather than 
only too late to return such error status.

>   Today, dynamic TLS areas are allocated using the public malloc
>   interface.  Programs or GC libraries or whatnot can today supply a
>   malloc replacement, scan the static data+bss area, scan each

Does overriding malloc as used within ld.so actually work, then?  I 
wouldn't have expected overriding necessarily to work for calls from 
ld.so, only for those from libc and other libraries.

-- 
Joseph S. Myers
joseph@codesourcery.com