Re: [RFC PATCH glibc 24/34] hurd: Only check for TLS initialization inside rtld or in static builds

[Sergey Bugaev <bugaevc@gmail.com>]

On Wed, Apr 12, 2023 at 12:00 PM Samuel Thibault
<samuel.thibault@gnu.org> 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-bdeca-c.c
-c -std=gnu11 -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=testsuite -include ../include/libc-symbols.h  -DPIC
-DSHARED     -DTOP_NAMESPACE=glibc -o
/home/sergey/glibc/build/elf/tst-dso-ordering9-dir/tst-dso-ordering9_42-bdeca-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