public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "slyfox at inbox dot ru" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/27033] New: glibc-2.32 on gcc-11 generates %fs:0x10 access before TLS is registered. Date: Tue, 08 Dec 2020 00:36:19 +0000 [thread overview] Message-ID: <bug-27033-131@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=27033 Bug ID: 27033 Summary: glibc-2.32 on gcc-11 generates %fs:0x10 access before TLS is registered. Product: glibc Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: dynamic-link Assignee: unassigned at sourceware dot org Reporter: slyfox at inbox dot ru CC: hjl.tools at gmail dot com Target Milestone: --- Created attachment 13025 --> https://sourceware.org/bugzilla/attachment.cgi?id=13025&action=edit gcc-11-glibc-tls.tar.gz Noticed the failure as a crash of binaries ran against glibc-2.32. glibc-2.32 is built by gcc-11. The backtrace: $ gdb --args ./ld-*.so --library-path . /usr/bin/cal (gdb) run Program received signal SIGSEGV, Segmentation fault. (gdb) bt #0 0x00007ffff7fdcbe7 in add_dependency (flags=<optimized out>, map=<optimized out>, undef_map=<optimized out>) at dl-lookup.c:640 #1 _dl_lookup_symbol_x (undef_name=0x7ffff7ff4141 "__vdso_clock_gettime", undef_map=0x7ffff7ffe770, ref=0x7fffffffe198, symbol_scope=0x7ffff7ffeb08, version=0x7fffffffe1c0, type_class=0, flags=0, skip_map=0x0) at dl-lookup.c:929 #2 0x00007ffff7fd5648 in dl_vdso_vsym (name=0x7ffff7ff4141 "__vdso_clock_gettime") at ../sysdeps/unix/sysv/linux/dl-vdso.h:52 #3 setup_vdso_pointers () at ../sysdeps/unix/sysv/linux/dl-vdso-setup.h:30 #4 dl_main (phdr=<optimized out>, phdr@entry=0x7ffff7fd2040, phnum=11, phnum@entry=8, user_entry=user_entry@entry=0x7fffffffe420, auxv=0x7fffffffe5d8) at rtld.c:1614 #5 0x00007ffff7feba79 in _dl_sysdep_start (start_argptr=start_argptr@entry=0x7fffffffe4e0, dl_main=dl_main@entry=0x7ffff7fd44a0 <dl_main>) at ../elf/dl-sysdep.c:252 #6 0x00007ffff7fd3fc5 in _dl_start_final (arg=0x7fffffffe4e0) at rtld.c:506 #7 _dl_start (arg=0x7fffffffe4e0) at rtld.c:599 ... (gdb) disassemble Dump of assembler code for function _dl_lookup_symbol_x: 0x00007ffff7fdcbd0 <+0>: push %r15 0x00007ffff7fdcbd2 <+2>: push %r14 0x00007ffff7fdcbd4 <+4>: push %r13 0x00007ffff7fdcbd6 <+6>: mov %rdx,%r13 0x00007ffff7fdcbd9 <+9>: push %r12 0x00007ffff7fdcbdb <+11>: mov %rdi,%r12 0x00007ffff7fdcbde <+14>: push %rbp 0x00007ffff7fdcbdf <+15>: push %rbx 0x00007ffff7fdcbe0 <+16>: sub $0xa8,%rsp => 0x00007ffff7fdcbe7 <+23>: mov %fs:0x10,%rax 0x00007ffff7fdcbf0 <+32>: mov %rsi,0x10(%rsp) Note: 'mov %fs:0x10,%rax' is a 'THREAD_GSCOPE_RESET_FLAG ();' call. I'm not sure if it's a glibc bug of using the macro in rtld before TLS is set up (or a missing compiler barrier) or a gcc bug of hoisting the %fs: access outside an 'if (__builtin_expect ((flags & DL_LOOKUP_GSCOPE_LOCK), 0))' condition. I'm assuming it's a glibc bug. Attached gcc-11-glibc-tls.tar.gz contains: 1. preprocessed dl-lookup.c file 2. script to compile dl-loookup.c into .o and .S files with gcc-10 and gcc-11. 3. .o and .S files as well for both gcc-10 (good) and gcc11 (bad) files. 10.s (good) entry _dl_lookup_symbol_x: 0x0000000000000d40 <+0>: push %r15 0x0000000000000d42 <+2>: push %r14 0x0000000000000d44 <+4>: push %r13 0x0000000000000d46 <+6>: mov %rdx,%r13 0x0000000000000d49 <+9>: push %r12 0x0000000000000d4b <+11>: mov %rdi,%r12 0x0000000000000d4e <+14>: push %rbp 0x0000000000000d4f <+15>: push %rbx 0x0000000000000d50 <+16>: sub $0x98,%rsp 0x0000000000000d57 <+23>: movzbl (%rdi),%edx 0x0000000000000d5a <+26>: mov %rsi,0x10(%rsp) 0x0000000000000d5f <+31>: mov %rcx,0x20(%rsp) 0x0000000000000d64 <+36>: mov %r8,0x8(%rsp) 0x0000000000000d69 <+41>: mov %r9d,0x1c(%rsp) 0x0000000000000d6e <+46>: test %dl,%dl 11.s (bad) entry _dl_lookup_symbol_x: 0x0000000000000d70 <+0>: push %r15 0x0000000000000d72 <+2>: push %r14 0x0000000000000d74 <+4>: push %r13 0x0000000000000d76 <+6>: push %r12 0x0000000000000d78 <+8>: mov %rdi,%r12 0x0000000000000d7b <+11>: push %rbp 0x0000000000000d7c <+12>: mov %rdx,%rbp 0x0000000000000d7f <+15>: push %rbx 0x0000000000000d80 <+16>: mov %fs:0x10,%rax ; <<<- bad, crashes libc 0x0000000000000d89 <+25>: sub $0xa8,%rsp 0x0000000000000d90 <+32>: mov %rsi,0x10(%rsp) 0x0000000000000d95 <+37>: mov %rcx,0x20(%rsp) 0x0000000000000d9a <+42>: mov %r8,0x8(%rsp) 0x0000000000000d9f <+47>: mov %r9d,0x1c(%rsp) 0x0000000000000da4 <+52>: mov %rax,0x30(%rsp) 0x0000000000000da9 <+57>: movzbl (%r12),%edx 0x0000000000000dae <+62>: test %dl,%dl -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2020-12-08 0:36 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-08 0:36 slyfox at inbox dot ru [this message] 2020-12-08 0:46 ` [Bug dynamic-link/27033] " hjl.tools at gmail dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-27033-131@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).