On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > > Hello, > > Had you actually tested it on i386? It seems to be breaking the > testsuite completely. I would expect that a submitted patch series has > gone through the testsuite.
Ouch! I have tested that it works on i386, as in I was able to run bash and apt with it. I'll re-check whether it (still) works, maybe I'm misremembering and my testing wasn't with the latest iteration of the change (although I'm fairly sure that it was, hm). I have not run the testsuite, because: * I'm cross-compiling * I never managed to run it to completion on the Hurd in the first place... but maybe you have already fixed this. I'll try to run the full testsuite once I get to my other machine. But also, I think I've made it clear enough that this is an RFC and while I have done some testing, it wasn't comprehensive. I was happy to see it pushed, but that's because I assumed that you have verified that my assumptions & reasoning are sound and that this change doesn't break anything. Please don't just blindly trust me with this patchset! > Sergey Bugaev, le dim. 19 mars 2023 18:10:07 +0300, a ecrit: > > When glibc is built as a shared library, TLS is always initialized by > > the call of TLS_INIT_TP () macro made inside the dynamic loader, prior > > to running the main program (see dl-call_tls_init_tp.h). > > Yes, but apparently we load libc.so before calling TLS_INIT_TP? (and > thus start using its functions) If that was the case, wouldn't we also explode on e.g. errno accesses? Note that the Hurd port doesn't use RTLD_PRIVATE_ERRNO. As I understand it, rtld starts using libc functions after the call to _dl_relocate_object (&GL(dl_rtld_map), main_map->l_scope, 0, 0) at elf/rtld.c:2372. TLS has already been initialized by that point, and in fact there's a comment there saying, "We must do this after TLS initialization in case after this re-relocation, we might call a user-supplied function (e.g. calloc from _dl_relocate_object) that uses TLS data." Here's some evidence to support that theory: I've uploaded a log with LD_DEBUG + gdb here: [0]. As you can see, i386_set_gdt gets hit *way* before ld.so gets reallocated / bound to libc.so symbols. The same can be seen in a file that explicitly links against libdl (this doesn't seem to make any difference). [0]: https://paste.gg/p/anonymous/ae39453264334d3e92670a3cd964806d But of course it's hard to argue with test failures :( > I'm thinking that we should as well just assume that the hardware is old > enough to support rdfsbase, that'll be *way* simpler to test for TLS. Maybe that, yes. > I have reverted that change for now, so we get back to a working glibc. Good. Sergey
