[Bug d/113081] New: static linking does not work

[Bug d/113081] New: static linking does not work

[rguenth at gcc dot gnu.org]

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

            Bug ID: 113081
           Summary: static linking does not work
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: d
          Assignee: ibuclaw at gdcproject dot org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Trying to statically link a Hello World doesn't work:

import std.stdio;

void main()
{
    writeln("Hello, World!");
}

> gdc-13 t.d -static
...
/usr/lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/bin/ld:
/usr/lib64/gcc/x86_64-suse-linux/13/libgphobos.a(elf.o): in function
`_D3gcc8sections3elf11getTLSRangeFNbNimmZAv':
/home/abuild/rpmbuild/BUILD/gcc-13.2.1+git7813/obj-x86_64-suse-linux/x86_64-suse-linux/libphobos/libdruntime/../../../../libphobos/libdruntime/gcc/sections/elf.d:1095:(.text._D3gcc8sections3elf11getTLSRangeFNbNimmZAv+0x29):
undefined reference to `__tls_get_addr'
collect2: error: ld returned 1 exit status

that's libphobos/libdruntime/gcc/sections/elf.d:1095

void[] getTLSRange(size_t mod, size_t sz) nothrow @nogc
{
...
        else
            return (__tls_get_addr(&ti)-TLS_DTV_OFFSET)[0 .. sz];
    }
}

not using a TLS relocation but an explicit call.  A TLS relocation would
have been resolved/relaxed at static link time but an explicit call of
course prevails.

Linking the Hello World with -static-libphobos works (there is no
-static-libdruntime but libgdruntime.so.4 doesn't seem to be DT_NEEDED
on the executable?).

Maybe putting the TLS module helpers into a separate object (so not
statically linked when not needed) might help, implementing the helpers
in a way that allow static linking might be possible as well (by
using actual __tls declarations?).

[Bug d/113081] static linking does not work

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug d/113081] static linking does not work

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
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

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(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.