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 E3CD43858D28 for ; Tue, 11 Apr 2023 21:23:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E3CD43858D28 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 1pmLSu-00069z-CV; Tue, 11 Apr 2023 17:23:48 -0400 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=LcnNVQF5zW+zn3cixJzCz6Sf6vbbzVwOamjBshPMK1E=; b=sWxKWljL6cwIV2Nt13Tx My+JdMaHOm2Tp/jeBIso0fZ4puE9XNr2DNFI67GTS5iMmTduKFviuimmsK/iqgyvt2FMB81rVZhIh HzKPQDrlcaKETgKu2EAUUfhzI5WmZU5N2xKd1HqN7NIGiD62Ke9B19T8vb7fRsP58OIN1FtaHWThs ShCde6Pz4jqZJmPiYId0N01LzeCePTKh1ozbuiGahWJYQ/fHoZ7cjJTJXWGH5PX9vxBxmdeyBjeV3 YVY8V2A5NqHx2c5dyuf7SyIQhSYQWU1gfVQQMCrLf8mZHI8B3Jvhqnh0I9rOsxXQ52flJM+bd3Rm7 wLJ9ZWYHao+KOA==; 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 1pmLSu-0004au-3T; Tue, 11 Apr 2023 17:23:48 -0400 Received: from samy by begin with local (Exim 4.96) (envelope-from ) id 1pmLSs-000irk-1q; Tue, 11 Apr 2023 23:23:46 +0200 Date: Tue, 11 Apr 2023 23:23:46 +0200 From: Samuel Thibault To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds Message-ID: <20230411212346.ligmclr5ph7gowl5@begin> Mail-Followup-To: Sergey Bugaev , libc-alpha@sourceware.org, bug-hurd@gnu.org References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-25-bugaevc@gmail.com> <20230411185705.22jygrepjq4mhbvk@begin> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Organization: I am not organized User-Agent: NeoMutt/20170609 (1.8.3) X-Spam-Status: No, score=-5.6 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,URIBL_BLACK autolearn=no 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, le mar. 11 avril 2023 23:27:35 +0300, a ecrit: > On Tue, Apr 11, 2023 at 9:57 PM Samuel Thibault 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