Hello, On Thu, May 18, 2023 at 9:55 PM Joseph Myers <jos...@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
