From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) by sourceware.org (Postfix) with ESMTPS id 54FEA3858D28 for ; Wed, 12 Apr 2023 10:43:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 54FEA3858D28 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-oo1-xc31.google.com with SMTP id z8-20020a4ad1a8000000b00542190bf1fcso24891oor.9 for ; Wed, 12 Apr 2023 03:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681296181; x=1683888181; 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=G/XLlyX0cwLaR1pSRLSjWEZBdtLkjhF0pDE5U21/x4M=; b=oUC8I7YcnInoMbGd95QrIeCBi2vuwxAh5sNglRTskqiWAvSm8odGoORf368m6nBmEJ 0Z6XLmeLNkZjUt1wke7h85Req79KRg1PYAwrApp4EEaXqac/mYSSW5Frqf/eEy94VYkb Xay8c445/M/vh+iIRXE5mEQHk1prGmAFCD8rudtF/Db1RvSWOCp9YzbmzPML03DSSGmJ m8wUjTF3POSXXLzEumCJ08Y9ix6GU+lVc8jUut1Vt62CI77DCffbik+Er8wBwq5Yqw/f gi7NxNCulG0ZOXS3gvR07JOPcQUtBTF9sZ0aNcXlqquV+f+mE0NgJ2TzNMZHSdlqApRf HiMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681296181; x=1683888181; 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=G/XLlyX0cwLaR1pSRLSjWEZBdtLkjhF0pDE5U21/x4M=; b=KGbiGxYOUs9qZsXacc2B1cdStLuc35ctOhIrhar2vW7moBlYZbN6zyKa2Ln4AnyVzv 7z6liyU6mx/SZA4Kwf+HEQS3nYqxXHWmi5EiEYFmU8Q5P8eu/WA//kzB9KxM2sz/5wgr 0fmkxMIJJVweMWwCK8KBF64Z2T3LFnuGUN9FDlelXr+lf4Nn5UUpeXsF6tCr59QDB/sC 3oq5lb8/gd20fQGO8dX0Emfy3h7QbaEf+ShQAt4jzwBs0SU5ZIwJj5xybE5IyCwziHBs rXCWF7nCz68hpmztfjT53J0imYmF8sSykXkLsilm2Ovez3v/Xido5bqpri2A+six/8Ai 03zw== X-Gm-Message-State: AAQBX9dmlUipwMgZafLEr173t3Mm3hP7MmKB4PltOEgH/0UaUGbiO4wZ 93LaEg4fN3bj4nwwnlqmpyJDhKKf2yFYgcjmKxu5HHvkoxNuag== X-Google-Smtp-Source: AKy350Y20IrH2dXlNWnfJlkz+hLcN/hqrXbE6jOaW9MQCo3IycpUsEpnOuiRBAqTtpHxcgGkxcyTrVOy0lqdfXjS648= X-Received: by 2002:a05:6820:1509:b0:542:152b:c296 with SMTP id ay9-20020a056820150900b00542152bc296mr138108oob.0.1681296181500; Wed, 12 Apr 2023 03:43:01 -0700 (PDT) MIME-Version: 1.0 References: <20230319151017.531737-1-bugaevc@gmail.com> <20230319151017.531737-25-bugaevc@gmail.com> <20230411185705.22jygrepjq4mhbvk@begin> <20230411212346.ligmclr5ph7gowl5@begin> <20230412090025.rjqbtx2zakk5r6yx@begin> In-Reply-To: <20230412090025.rjqbtx2zakk5r6yx@begin> From: Sergey Bugaev Date: Wed, 12 Apr 2023 13:42:50 +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.7 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 Wed, Apr 12, 2023 at 12:00=E2=80=AFPM Samuel Thibault wrote: > Was that tst-spawn6? I can't point out any specific one :( There is just this huge wall of output, and then the whole thing breaks / hangs. FWIW, the last lines before my SSH / network stack died were: (Gmail is surely going to wrap this, but hopefully not too badly) gcc /home/sergey/glibc/build/elf/dso-sort-tests-src/tst-dso-ordering9_42-bd= eca-c.c -c -std=3Dgnu11 -fgnu89-inline -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -Wno-parentheses -Wstrict-prototypes -Wold-style-definition -fmath-errno -fPIC -I../include -I/home/sergey/glibc/build/elf -I/home/sergey/glibc/build -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd/x86 -I../sysdeps/mach/hurd/i386/htl -I../sysdeps/mach/hurd/htl -I../sysdeps/hurd/htl -I../sysdeps/mach/htl -I../sysdeps/htl/include -I../sysdeps/htl -I../sysdeps/pthread -I../sysdeps/mach/hurd/x86/htl -I../sysdeps/i386/htl -I../sysdeps/x86/htl -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd -I../sysdeps/unix/inet -I../sysdeps/mach/i386 -I../sysdeps/mach/x86 -I../sysdeps/mach/include -I../sysdeps/mach -I../sysdeps/i386/i686/fpu/multiarch -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686/multiarch -I../sysdeps/i386/i686 -I../sysdeps/i386/fpu -I../sysdeps/x86/fpu -I../sysdeps/i386 -I../sysdeps/x86/include -I../sysdeps/x86 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/hurd/include -I../sysdeps/hurd -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic -I../hurd -I/home/sergey/glibc/build/hurd/ -I../mach -I/home/sergey/glibc/build/mach/ -I.. -I../libio -I. -D_LIBC_REENTRANT -include /home/sergey/glibc/build/libc-modules.h -DMODULE_NAME=3Dtestsuite -include ../include/libc-symbols.h -DPIC -DSHARED -DTOP_NAMESPACE=3Dglibc -o /home/sergey/glibc/build/elf/tst-dso-ordering9-dir/tst-dso-ordering9_42-bde= ca-c.os client_loop: send disconnect: Broken pipe ...but that doesn't seem useful. > You can run on master to get the list of current expected failures. But that's the thing, I can not :| > > Could you please point me to a specific test case > > Actually all cases that actually execute something, fail. So for > instance the very first, csu/test-as-const-rtld-sizes That one seems to have passed: sergey@hurdle:~/glibc/build$ cat csu/test-as-const-rtld-sizes.out sergey@hurdle:~/glibc/build$ cat csu/test-as-const-rtld-sizes.test-result PASS: csu/test-as-const-rtld-sizes original exit status 0 this is with your revert reverted. Here's some more evidence that compiling out the no-tls case should be safe, about errno again: (gdb) info symbol 0x00023670 __errno_location in section .text of /lib/ld.so (gdb) disas 0x00023670 Dump of assembler code for function __errno_location: 0x00023670 <+0>: call 0x2919a <__x86.get_pc_thunk.ax> 0x00023675 <+5>: add $0x1297f,%eax 0x0002367a <+10>: lea 0xa24(%eax),%eax 0x00023680 <+16>: ret End of assembler dump. (gdb) info symbol 0x01077f00 __errno_location in section .text of /lib/i386-gnu/libc.so.0.3 (gdb) disas 0x01077f00 Dump of assembler code for function __GI___errno_location: 0x01077f00 <+0>: call 0x1220bc1 <__x86.get_pc_thunk.ax> 0x01077f05 <+5>: add $0x22e0ef,%eax 0x01077f0a <+10>: mov -0x1b8(%eax),%eax 0x01077f10 <+16>: add %gs:0x0,%eax 0x01077f17 <+23>: ret End of assembler dump. This is what's shipped in Debian, i.e. prior to my changes. As you can see, the libc.so version accesses %gs:0x0 without any checks, which makes sense, since __errno_location is just return &errno, 'errno' itself being a thread-local. There is no __LIBC_NO_TLS check in the source code. And yet it works just fine! It follows that all __LIBC_NO_TLS checks in libc.so must be redundant. > > Would it have been easy for me to run the full test suite, I would > > surely do that before submitting any patches. But it's not. > > Then it's simple: we have to fix that first. If that's simple to fix, great! Can you reproduce my issues? Sergey