On Tuesday, 13 October 2020 at 11:27:45 UTC, Denis Feklushkin wrote:
> On Tuesday, 13 October 2020 at 11:23:23 UTC, IGotD- wrote:
>> On Tuesday, 13 October 2020 at 11:13:16 UTC, Denis Feklushkin wrote:
>>>
>>> But it is still not clear why static variables are now not "superimposed" on one another at the same addresses.
>>>
>>
>> If you don't have emulated TLS, your build shouldn't even succeed if you haven't implemented __tls_get_address. So if you have a build that you can test, where does this __tls_get_address come from?
>
> It is provided by "picolibc" library.
>
> Actually it provides __aeabi_read_tp but I wrap it:
> https://github.com/denizzzka/d_c_arm_test/blob/master/d/freertos_druntime_backend/external/rt/sections.d#L45

The function prototype of __tls_get_address is wrong. It should be

struct tls_index
{
	size_t ti_module;
	size_t ti_offset;
};

void* __tls_get_addr(tls_index* ti)


You perhaps don't use modules but you certainly need an offset.

It should rather be something like

void* __tls_get_addr(tls_index* ti)
{
    return getThreadTlsArea(ti->ti_module) + ti->ti_offset;
}

On Tuesday, 13 October 2020 at 11:38:33 UTC, IGotD- wrote:
>
> The function prototype of __tls_get_address is wrong. It should be
>
> struct tls_index
> {
> 	size_t ti_module;
> 	size_t ti_offset;
> };
>
> void* __tls_get_addr(tls_index* ti)
>
>
> You perhaps don't use modules but you certainly need an offset.
>
> It should rather be something like
>
> void* __tls_get_addr(tls_index* ti)
> {
>     return getThreadTlsArea(ti->ti_module) + ti->ti_offset;
> }

Just to add to the confusion. If you compile everything statically into one binary, __tls_get_addr should never really be called at least with C/C++. Then the compiler should optimize and call __aeabi_read_tp directly. The compiler inserts TP + offset itself instead as it assumes all statically and dynamically linked that are loaded during program start have already allocated the TLS area and TP is valid.

However, I've seen that D seems to insert calls __tls_get_addr anyway like the initial exec model optimization doesn't exist. That's a question if that model is implemented in D.

On Tuesday, 13 October 2020 at 11:38:33 UTC, IGotD- wrote:

>> It is provided by "picolibc" library.
>>
>> Actually it provides __aeabi_read_tp but I wrap it:
>> https://github.com/denizzzka/d_c_arm_test/blob/master/d/freertos_druntime_backend/external/rt/sections.d#L45
>
> The function prototype of __tls_get_address is wrong.

It is implemented inside of LLVM?
Can you provide link to right declaration?

Google full of "__tls_get_addr()" form

> It should be
>
> struct tls_index
> {
> 	size_t ti_module;
> 	size_t ti_offset;
> };
>
> void* __tls_get_addr(tls_index* ti)
>
>
> You perhaps don't use modules but you certainly need an offset.
>
> It should rather be something like
>
> void* __tls_get_addr(tls_index* ti)
> {
>     return getThreadTlsArea(ti->ti_module) + ti->ti_offset;
> }

Yep, sounds like the correct explanation of my issue! Thanks!

On Tuesday, 13 October 2020 at 12:00:34 UTC, Denis Feklushkin wrote:
> On Tuesday, 13 October 2020 at 11:38:33 UTC, IGotD- wrote:
>
>>> It is provided by "picolibc" library.
>>>
>>> Actually it provides __aeabi_read_tp but I wrap it:
>>> https://github.com/denizzzka/d_c_arm_test/blob/master/d/freertos_druntime_backend/external/rt/sections.d#L45
>>
>> The function prototype of __tls_get_address is wrong.
>
> It is implemented inside of LLVM?
> Can you provide link to right declaration?
>

Don't worry, found it. Thanks again!

On Tuesday, 13 October 2020 at 12:00:34 UTC, Denis Feklushkin wrote:
>
> It is implemented inside of LLVM?
> Can you provide link to right declaration?
>
> Google full of "__tls_get_addr()" form
>

Sorry, I can't because it is a mess. I think that __tls_get_addr is connected to an ELF standard for thread-local storage.

https://akkadia.org/drepper/tls.pdf

Note that the document doesn't include ARM but Itanium and other unusual CPUs. However declaration of __tls_get_addr is stated there for other CPUs than ARM. I've seen other versions of __tls_get_addr out there as well and it can be architecture dependent. Also keep in mind that I use ARMv7-ar as reference point here, I cannot 100% say that it is the same for Cortex M3. The RunTime ABI for ARM

http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C3E4EA7E008BA776DF7E0F54C8F7CCF1?doi=10.1.1.352.5218&rep=rep1&type=pdf

isn't really that helpful either.

On Tuesday, 13 October 2020 at 12:33:57 UTC, IGotD- wrote:

> Sorry, I can't because it is a mess. I think that __tls_get_addr is connected to an ELF standard for thread-local storage.

Looks like this problem is solvable: it is possible to push through own implementation of (emu)TLS by replacing it in the linker (--wrap=). Emutls implementation not tied to anything.

On Thursday, 15 October 2020 at 01:23:53 UTC, Denis Feklushkin wrote:
>
> Looks like this problem is solvable: it is possible to push through own implementation of (emu)TLS by replacing it in the linker (--wrap=). Emutls implementation not tied to anything.

That's the same as implementing your own version so you don't need the TLS emulation at all. TLS in a static system isn't that difficult.

https://wiki.osdev.org/Thread_Local_Storage

The only thing you need to implement is __tls_get_addr and possibly __aeabi_read_tp.

On Thursday, 15 October 2020 at 15:09:45 UTC, IGotD- wrote:
> On Thursday, 15 October 2020 at 01:23:53 UTC, Denis Feklushkin wrote:
>>
>> Looks like this problem is solvable: it is possible to push through own implementation of (emu)TLS by replacing it in the linker (--wrap=). Emutls implementation not tied to anything.
>
> That's the same as implementing your own version so you don't need the TLS emulation at all.

I am not sure, but looks like different arguments for __tls_get_addr will be used in case if emulation is enabled and disabled?

If emulation will be used arguments is same as for gcc and these args allows you to avoid ELF-related things.