From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 3695D3858D33 for ; Wed, 22 Feb 2023 23:32:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3695D3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUybV-0006oC-F5; Wed, 22 Feb 2023 18:32:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=In-Reply-To:MIME-Version:References:Subject:To:From: Date; bh=f/1AzfKmTIzf0w6NJO6grktPIRTQKhbfQ23+VpEEQb4=; b=ozeiqG8YqTJD/NIeTMnx qq61o+tPheIZKIF6hOTm+bSjRkrHq1Qg6KDaiVEHN7vztcTfVvXiLOF3HL0sDAzVDjfHrITCEinJN ZK7n1kdRm7hSLIxiYnWWmfpb8YbqWjkDZ/UJ7ZJvhslBLJaBv/ElLuXl6TAIWdmn9TSprOowUuKIz gBaYj8tJQUymO5RRP4nw9VGJfzS/bC+PoxuB9BpMJX2ko5wNXkb9L8b7OgC/Q+HTCaNO6gMshj6AK vjCORLvf9EJrBjOkgmwjGJaCeDtYReVla9g73iJBu9A2RpwEVzfE0jra/4gttmYj8gC4/GaMJB5EV efuQFILm9LGBpQ==; Received: from [2a01:cb19:4a:a400:de41:a9ff:fe47:ec49] (helo=begin) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUybV-0004e5-0z; Wed, 22 Feb 2023 18:32:53 -0500 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pUybT-007MMY-1F; Thu, 23 Feb 2023 00:32:51 +0100 Date: Thu, 23 Feb 2023 00:32:51 +0100 From: Samuel Thibault To: Sergey Bugaev Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz , Noah Goldstein Subject: Re: [PATCH v2 0/4] More x86_64-gnu glibc work Message-ID: <20230222233251.gzcjay3tm275gtgp@begin> Mail-Followup-To: Sergey Bugaev , bug-hurd@gnu.org, libc-alpha@sourceware.org, =?utf-8?Q?Fl=C3=A1vio?= Cruz , Noah Goldstein References: <20230221211932.296459-1-bugaevc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230221211932.296459-1-bugaevc@gmail.com> Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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