Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

[Sergey Bugaev]

On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault <samuel.thibault@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