[Bug d/113081] static linking does not work

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081

--- Comment #3 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #2)

> If I recall correctly, this trick is not guaranteed to work (for a
> drtbegin.o and drtend.o object), as there really no control over where in
> the TLS section these variables will land.
> 
> ```
> #ifdef DRT_BEGIN
> _Thread_local __SIZE_TYPE__ __tls_start = 3;
> #endif
> 
> #ifdef DRT_END
> _Thread_local __SIZE_TYPE__ __tls_end;
> #endif
> ```
Both of these rely on the default linker script of:
 .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
 .tbss  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) }
to group the sections in that order.

According to some old commit notes of mine for gdc in 2013, ld can reorder
.tdata after .tdata.*, despite what the linker script says.

[Bug d/113081] static linking does not work

[ibuclaw at gdcproject dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081

--- Comment #2 from Iain Buclaw  ---
It could be moved to drtstuff.o to avoid it being in the library, but unless
there's an equivalent function available there'll be crashes caused by the GC
free'ing live objects as it did not scan all TLS variables for the executing
thread.

If I recall correctly, this trick is not guaranteed to work (for a drtbegin.o
and drtend.o object), as there really no control over where in the TLS section
these variables will land.

```
#ifdef DRT_BEGIN
_Thread_local __SIZE_TYPE__ __tls_start = 3;
#endif

#ifdef DRT_END
_Thread_local __SIZE_TYPE__ __tls_end;
#endif
```

[Bug d/113081] static linking does not work

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113081

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-19
   Keywords||link-failure
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.