[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
[PATCH v2 2/4] hurd: Generalize init-first.c to support x86_64, Sergey Bugaev, 2023/02/21
[PATCH v2 3/4] hurd: Implement TLS for x86_64, Sergey Bugaev, 2023/02/21
[PATCH v2 4/4] htl: Add pthreadtypes-arch.h for x86_64, Sergey Bugaev, 2023/02/21
Re: [PATCH v2 0/4] More x86_64-gnu glibc work,
Samuel Thibault <=