Re: [RFC PATCH 06/10] hurd: Make sure to not use tcb->self

[Sergey Bugaev <bugaevc@gmail.com>]

Hello,

On Thu, May 18, 2023 at 9:55 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> I suspect this of causing linknamespace test failures:
>
> Contents of conform/POSIX2008/pthread.h/linknamespace.out:
>
> [initial] pthread_create -> [libpthread.a(pt-create.o)] __pthread_setup -> [libpthread.a(pt-setup.o)] hurd_thread_self
>
> (On x86_64 there's also a localplt test failure: "Extra PLT reference:
> libc.so: hurd_thread_self".  In addition, x86_64 has a c++-types-check
> failure.  Thus, neither Hurd configuration has clean results for
> compilation tests from build-many-glibcs.py at present.)

Thank you, and sorry :|

Do I understand it right that this is because of hurd_thread_self
being publicly exported and interposable? A quick grep shows that
nothing else inside glibc was using hurd_thread_self indeed.

Would the right way to resolve this be introducing a hidden
__hurd_thread_self and using that? We could also make it
__mach_thread_self () + __mach_port_deallocate (), but why do +2
syscalls when we already have all the required info in userspace.

What's the C++ type check failure? Surely this patch (nor
2f8ecb58a59eb82c43214d000842d99644a662d1 "hurd: Fix x86_64
_hurd_tls_fork") has modified any public headers?

Sergey