__emutls_v & __emutls_t

Iain Buclaw ibuclaw at gdcproject.org
Sun Dec 22 13:46:06 PST 2013


On 22 December 2013 12:54, Timo Sintonen <t.sintonen at luukku.com> wrote:
> Had a quick look at emutls.d.
> Yes, the rodata section  have the initial values of variables. This should
> be copied to the tls area of the current thread as I wrote earlier.
> The data section does not contain data, but those emutls objects. They
> contain the pointer to the data and the size of data, among others. This
> section should be in rom and copied to ram within other data sections.
>
> This paragraf is again a guess.
> The compiler knows which object belongs to which variable. It fills the
> structures for those variables that are in rodata. For big uninitialized
> data like structs and arrays the emutls object contains initially a null
> pointer. Only when referencing this object first time, the data is allocated
> with malloc.
>
>
> When addressing the actual variable, the offset is picked from the
> corresponding emutls object and added to the tls start address which is
> gotten from the thread library. This adds one extra level of indirection,
> but there is one advantage: because there is only one tls, all threads have
> all tls data from all modules. Emutls only allocates the data that really is
> used in that thread and the initial tls size is much smaller.
>
> Anyway, this is not for us minimalists. The original emutls code has calls
> to  libpthread and so is not usable. It might be possible to make an own
> __emutls_get_address and I may have a look at it.
>

That's actually calls to gthread, which is a small libpthread inspired
wrapper library.  But the meaning is implied, all thread models
supported by gcc are wrappers around the platform's pthread library,
with exception to win32 (uses CriticalSection) and single (just
stubs).

Regards
Iain


More information about the D.gnu mailing list