Fix phdr_tls_data for static binaries; Fix recursion on rtld_bind_lock in dynamic dl_iterate_phdr

[kib]

Summary

This change make phdr_tls_data to be the address of the TLS segment for current thread, both for static and dynamic binaries.

Also it adds _get_tp() libc function that returns TCB. Its existence makes many things in TLS handling easier (but I did not converted all __tls_get_address() to use _get_tp()).

Per-commit split of the diff can be seen at https://kib.kiev.ua/git/gitweb.cgi?p=deviant3.git;a=shortlog;h=refs/heads/phdr_tls_data

I would appreciate both review and even more, test of the patch on non-x86 architectures. In fact, even checking that TLS still works is great. Since there is a regression in dl_iterate_phdr() fixed by this change, I want to commit this ASAP (and do not want to revert the buggy commit due to versioning changes included)

[andrew]

lib/libc/arm/gen/_get_tp.c

45–47 ↗

(On Diff #86947)

How far back are you planning to MFC this? This is needed in 12, but not 13 or later. I've created D29624 to remove it from HEAD.

[kib]

lib/libc/arm/gen/_get_tp.c

45–47 ↗

(On Diff #86947)

13 definitely. So far rtld code was synced between 12/13/HEAD, so I will do put some efforts to MFC to 12. I do not think that removal of ARM_TP_ADDRESS would be hard to handle, although I cannot test the merge result. I mean, it might be slightly simpler if removal was done after my changes go in.

[mhorne]

lib/libc/gen/tls.c

44 ↗

(On Diff #86947)

This results in a redefinition error for TLS_TCB_SIZE since it is defined in rtld_machdep.h for some archs, and then again in this file.

116 ↗

(On Diff #86947)

Can you use DTV_OFFSET defined above? I could be wrong, but it seems like doing so would be enough to avoid the rtld.h include.

[kib]

The version of the patch survived tinderbox

[bdragon]

Testing libexec/rtld-elf, lib/csu, lib/libthr on powerpc*.

Looks good on powerpc/powerpc and powerpc/powerpcspe (32 bit). Will continue testing other powerpc variants.

By the way, doesn't the new _get_tp need to be exposed in the FBSDprivate_1.0 namespace in the Symbol.map files like _set_tp is? (Especially on mips, where it can be a sysarch still?)

[kib]

In D29623#664356, @bdragon wrote:

Testing libexec/rtld-elf, lib/csu, lib/libthr on powerpc*.

Looks good on powerpc/powerpc and powerpc/powerpcspe (32 bit). Will continue testing other powerpc variants.

Thank you for the testing.

By the way, doesn't the new _get_tp need to be exposed in the FBSDprivate_1.0 namespace in the Symbol.map files like _set_tp is? (Especially on mips, where it can be a sysarch still?)

So far consumers of _get_tp() are either libc itself, or rtld which links to the special static version of libc. In other words, there is no in-tree consumer that would use the symbol in the libc.so.

[bdragon]

Oh! So it's not a contract between libc and rtld, it's just internal functionality that is used in both static libc as well as rtld, so it ends up being hidden visibility and just a common piece of code that both happen to pull in. Makes sense to me now.

powerpc/powerpc64 tested. I also built powerpc/powerpc64le, but won't get a chance to test it tonight. I don't expect it to be any different than powerpc64 though, since powerpc64 and powerpc64le share code.

powerpcspe and powerpc64 also got through all of the lib/libc tests with no additional failures (on top of the handful of preexising failures that I haven't gotten around to sorting out yet that have been around for months)

No objections from a PowerPC standpoint.

[kib]

Rebase after removal of ARM_TP_ADDRESS

[mhorne]

The latest version boots okay on riscv. I ran the libc and rtld test suites as well.

[bdragon]

Retested powerpc/powerpcspe. Still good.