feklushkin.denis at gmail.com
Tue Oct 13 11:13:16 UTC 2020
On Tuesday, 13 October 2020 at 11:02:56 UTC, IGotD- wrote:
> On Tuesday, 13 October 2020 at 10:35:57 UTC, Denis Feklushkin
>> So, compiler knows what this platform is not supports
>> multithreading and does some things wrong with thread static
>> variables if "--emulated-tls" is ommited?
> You can see the implementation yourself.
> I have used TLS emulation myself and it just works despite the
> library has no definition of threads or mutexes so I guess
> these are just stubs or use stubs in the C library in that
> case. Basically single threaded TLS.
>> As I understand, variables allocated by compiler, but it uses
>> internal implict call to __tls_get_addr to provide access to
> If SW call is chosen then __tls_get_addr is the function that
> is used in order to obtain the address of a TLS variable. If
> emulation is used this function is just forwarded to the
> emulation function. It is almost easier to implement
> __tls_get_addr yourself and skip the emulation.
Ok, I see in my binary what if I use "--emulated-tls" 3-rd party
function __tls_get_address (provided by picolibc) replaced by
But it is still not clear why static variables are now not
"superimposed" on one another at the same addresses.
> If you look at the emulation layer it is filled with mutexes
> and mallocs and on simple systems this can be totally avoided
> if you use your own solution. Especially in real-time systems,
> the emulation layer should not be used for obvious reasons.
Yes, we already have fibers for this. However, at least one TLS
must be created that belongs to the main thread.
More information about the digitalmars-d-ldc