Re: [PATCH] Fix TLS relocations against local symbols on powerpc32, sparc32 and sparc64

[Alan Modra <amodra at gmail dot com>]

On Sat, Sep 02, 2017 at 07:08:01PM +0100, James Clarke wrote:
> Normally, TLS relocations against local symbols are optimised by the linker to
> be absolute. However, gold does not do this, and so it is possible to end up
> with, for example, R_SPARC_TLS_DTPMOD64 referring to a local symbol.

That is actually correct behaviour.  The linker can't resolve DTPMOD
relocs in a shared library at link time, since it doesn't know the
tls module id that will be assigned at run time.  So a dynamic DTPMOD
reloc must be emitted against a local symbol or SHN_UNDEF (symbol
index zero).  There are other cases too where TLS relocs must be
dynamic in a shared library.  For example, TPREL relocs must be
dynamic because the linker doesn't know where the TLS segment of the
library will be laid out relative to the thread pointer.

I guess what you're really saying is that gold doesn't make use of the
fact that glibc ld.so handles symbol index zero in these cases, but
instead emits a local dynamic symbol to use by the dynamic reloc.

> Since
> sym_map is left as null in elf_machine_rela for the special local symbol case,
> the relocation handling thinks it has nothing to do, and so the module gets
> left as 0.

Yes, thanks for noticing!  The only time we should have sym_map NULL
is for an undefined weak symbol.  The patch looks good to me.

-- 
Alan Modra
Australia Development Lab, IBM