The implementation of dl_iterate_phdr abuses tls_get_addr_slow to get to
the start of the TLS block, inlining the implementation of
tls_get_addr as if the tls_index's ti_offset were 0 (historically it
called tls_get_addr itself but changed due to locking issues). For
most architectures, tls_index's ti_offset (relocated by DTPOFF/DTPREL
for GOT entries) is just the offset within that module's TLS block.
However, for PowerPC and RISC-V, which have a non-zero TLS_DTV_OFFSET
and thus are designed assuming DTV entries are biased by that value,
ti_offset normally has TLS_DTV_OFFSET pre-subtracted, but it's
__tls_get_addr's responsibility to compensate for that. By using an
offset of zero here, tls_get_addr_slow will return a pointer to the
start of the TLS block itself, so by adding TLS_DTV_OFFSET we will point
TLS_DTV_OFFSET past the module's TLS block.

Fix this by removing the extra bias (the alternative would be to pass
-TLS_DTV_OFFSET and keep the addition, which would more closely follow
what __tls_get_addr does, but this is more direct).

(Note this also applies to MIPS on stable/13)

Fixes: d36d68161517 ("rtld dl_iterate_phdr(): dlpi_tls_data is wrong")
MFC after: 1 week