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

[Samuel Thibault]

Sergey Bugaev, le mar. 11 avril 2023 23:27:35 +0300, a ecrit:
> On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > 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,

Yes, some things work, but some others don't :)

> I have not run the testsuite, because:
> * I'm cross-compiling

You can probably push your tree to a box where you can compile & run?

> * I never managed to run it to completion on the Hurd in the first
> place... but maybe you have already fixed this.

I have marked various tests as unsupported, yet.

> 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!

Sure, I did verify, but like everybody, the testsuite is in the end what
is best to make sure we haven't screwed up :)

> > 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.

I don't know.

> 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."

Ok, I don't know.

Samuel