[PATCH v4] ld/pe-dll: Don't auto-export symbols from .tls section

[Jan Beulich]

On 11.12.2025 10:29, LIU Hao wrote:
> I mistook the v2 patch in the previous message. This is actually the v3 patch.
> 
> 
> ---
> 
> The .tls section of an image contains template data that will be duplicated
> for each new thread to be created. Accessing thread-local data involves an
> image-specific global variable, _tls_used, for calculation. Therefore, it is
> impossible to export thread-local variables from a DLL.
> 
> The only symbol that exists in the .tls input section is _tls_start, but it's
> a CRT symbol and is never auto-exported. It's only necessary to check for
> user symbols, which are always generated in the subsection .tls$ by default,
> or in subsections like .tls$$<symbol> when -fdata-sections is specified.

This is all reasonably okay as far as C code goes. As previously mentioned, in
e.g. assembly code or with a custom linker script .tls itself could very well
be usable. (Of course with a custom linker script, significance of section
names goes away anyway when it comes to ld or bfd code.)

> --- a/ld/pe-dll.c
> +++ b/ld/pe-dll.c
> @@ -806,9 +806,16 @@ process_def_file_and_drectve (bfd *abfd ATTRIBUTE_UNUSED, struct bfd_link_info *
>   	    {
>   	      /* We should export symbols which are either global or not
>   		 anything at all.  (.bss data is the latter)
> -		 We should not export undefined symbols.  */
> +		 We should not export undefined symbols.
> +		 Compilers may generate template data (initializers) for
> +		 thread-local variables in .tls$* sections, but they are only
> +		 used by the DLL loader.  Symbols in those sections are not
> +		 used to access thread-local variables;

This is factually wrong. The symbols there _are_ used to access the variables,
just that the involved relocations are SECREL ones, i.e. ...

> only offsets to the
> +		 beginning of the .tls output section matter, but the offsets
> +		 can't be exported.

... yield offsets. The difficulty with using them from another binary is to
actually arrange for the SECREL-ness there (when the necessary information
isn't represented in .edata / .idata).

I'm sorry to be picky, but imprecise comments can do more harm than good.

Jan