From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 96FFE3858D32 for ; Tue, 11 Apr 2023 20:27:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 96FFE3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x22b.google.com with SMTP id m2so5870595oiw.0 for ; Tue, 11 Apr 2023 13:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681244867; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=rZcKE++/JW6W/CEvHegtFy9FKf5aehSVHkxeX7zHNd4=; b=d//T42XsJUUEwZKBqVk9ZSFjwffuBUGAQwLy9Gl0tH/6XW0OzHoZcjPcWf0rbiVA7/ aZu2mu5YZQghj63OAc2O0VVlue99Gutu4wHqXPD1W4O1crPw4jt3BA2BhPEMgpCieS/E 4XSGZZYQOgrNiH4qlqxTxLtuN9STZnNfvPQ3UDuv9R/o7h0x2Ib8KgoRtjycSQiLn8rI kFodbLl/q4JrLVxbkW6mx2kPHgEakqUU0PMBHTQg5h8giOjLP9cTRI1iQCZby8zeM29J PKD+2OUGsIcHTcHcjmVP5E/LAKTirRAUfl1QLotB7w8+Pq8LDIqBnJt/Vpxmkm+Kfn4g O1SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681244867; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rZcKE++/JW6W/CEvHegtFy9FKf5aehSVHkxeX7zHNd4=; b=kHDOMbdbzY258jARlQdo7IpIEuEddOQDrgM071U0yEYKs3qdFFOPp/YqM7GddZQI4u AxboWXBTJQly6TlIOrPdrOmJqZpWwm7d37T/qVVyljlkgqg+UE9+mWmQfI5tFRyfLr+k 4hUcWE2erJJW9WMrJUrqJGQiorHLPAKNXLtvBWSy8Or6R2rrbNLRLMqAy41RHG5Jy0rw h1g3tiStLz5bYhbLby5NH3Ls8oRb8A7K26VDN/+5TSQxxylpfBmAyFr7R+Ick0n8o0ii yW6VxGHI9lHDtziwpfxHU0LozO+8H19fSJolGpF07OninpGLcD/TB8lW0BekH9ppR8qh VXvg== X-Gm-Message-State: AAQBX9d0Eq9ZLCAvcjVND9xys13/BqpGaWpo7JTKZxJZkOBwP+9HDah+ Jo0SrubyBRnGADOMOhfUP0+6BkGQu0o09A7coyD8sTZ3vEU= X-Google-Smtp-Source: AKy350aPfGz1JvZLhGgvPf6OImCBrbHiGlqUvna806XP8gcB/O5ShGGHvfJC6qGOTct1wn+N8Cz0d2FKprsyg+FxpP4= X-Received: by 2002:a05:6808:1529:b0:38b:2f3f:c613 with SMTP id u41-20020a056808152900b0038b2f3fc613mr1147987oiw.4.1681244866753; Tue, 11 Apr 2023 13:27:46 -0700 (PDT) MIME-Version: 1.0 References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-25-bugaevc@gmail.com> <20230411185705.22jygrepjq4mhbvk@begin> In-Reply-To: <20230411185705.22jygrepjq4mhbvk@begin> From: Sergey Bugaev Date: Tue, 11 Apr 2023 23:27:35 +0300 Message-ID: Subject: Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds To: Samuel Thibault Cc: libc-alpha@sourceware.org, bug-hurd@gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: On Tue, Apr 11, 2023 at 9:57=E2=80=AFPM Samuel Thibault wrote: > > Hello, > > 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, maybe I'm misremembering and my testing wasn't with the latest iteration of the change (although I'm fairly sure that it was, hm). I have not run the testsuite, because: * I'm cross-compiling * I never managed to run it to completion on the Hurd in the first place... but maybe you have already fixed this. I'll try to run the full testsuite once I get to my other machine. 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! > 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. 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." Here's some evidence to support that theory: I've uploaded a log with LD_DEBUG + gdb here: [0]. As you can see, i386_set_gdt gets hit *way* before ld.so gets reallocated / bound to libc.so symbols. The same can be seen in a file that explicitly links against libdl (this doesn't seem to make any difference). [0]: https://paste.gg/p/anonymous/ae39453264334d3e92670a3cd964806d But of course it's hard to argue with test failures :( > I'm thinking that we should as well just assume that the hardware is old > enough to support rdfsbase, that'll be *way* simpler to test for TLS. Maybe that, yes. > I have reverted that change for now, so we get back to a working glibc. Good. Sergey