bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 0/4] More x86_64-gnu glibc work


From: Samuel Thibault
Subject: Re: [PATCH v2 0/4] More x86_64-gnu glibc work
Date: Thu, 23 Feb 2023 00:32:51 +0100
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev via Libc-alpha, le mer. 22 févr. 2023 00:19:28 +0300, a ecrit:
> Overall, I think this version is much cleaner.

Definitely :D

> I've tried to write some comments about how _hurd_stack_setup () works. 
> There's
> really not much code to it, but it is tricky, so better have it documented.

Thanks!

> As for x86_64, yes, I have verified that on x86_64-pc-linux-gnu argc/argv/env
> arrive on-stack just like the code in _hurd_stack_setup () expects them to.

Ok, good :)

> I still don't understand why __LIBC_NO_TLS () is supposed to return 0 when we
> have the early TLS configured, but this seems to be what the i386 version 
> does.

I don't remember the details, but most probably that's because there is
more to TLS than the mere early TLS. The gcc accesses are constants from
gs/fs so early TLS is enough. But e.g. _hurd_critical_section_lock would
try to access the sigstate, which will be in the eventual tcbhead, and
not in the early tcbhead.

> Note: this (TLS) still depends on the gnumach patch adding
> i386_fsgs_base_state. If the API is alright, can we push it without an
> implementation, so that userland code (glibc) can be built against it?

We can probably do that, yes.

Samuel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]