From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 8AB05385DC33 for ; Tue, 8 Jun 2021 21:53:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8AB05385DC33 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-34-g-FvXC3rMxmPQJIhMkqI-A-1; Tue, 08 Jun 2021 17:53:16 -0400 X-MC-Unique: g-FvXC3rMxmPQJIhMkqI-A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C3AA7801AEE; Tue, 8 Jun 2021 21:53:05 +0000 (UTC) Received: from f33-m1.lan (ovpn-113-207.phx2.redhat.com [10.3.113.207]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 90E975D9DC; Tue, 8 Jun 2021 21:53:05 +0000 (UTC) Date: Tue, 8 Jun 2021 14:53:04 -0700 From: Kevin Buettner To: Simon Marchi Cc: gdb-patches@sourceware.org, Florian Weimer , "Carlos O'Donell" Subject: Re: [PATCH v2] gdb: try to load libthread_db only after reading all shared libraries when attaching / handling a fork child Message-ID: <20210608145304.75f8d17e@f33-m1.lan> In-Reply-To: <35e8d467-62b9-49d8-2746-760791a85ce4@polymtl.ca> References: <20210330172149.1724381-1-simon.marchi@polymtl.ca> <20210504180245.3020757-1-simon.marchi@polymtl.ca> <20210604154206.7f8d48f3@f33-m1.lan> <35e8d467-62b9-49d8-2746-760791a85ce4@polymtl.ca> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_BLACK autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2021 21:53:19 -0000 On Tue, 8 Jun 2021 16:59:47 -0400 Simon Marchi wrote: > > Your patch doesn't solve all of the problems when using glibc 2.34. I > > have a one line fix (maybe hack) which allows us to do thread debugging > > when starting the program via "run" or "start". I'll post that > > patch separately, probably some time next week. (Basically, we now > > have to look for "libc" in addition to "libpthread" in order to trigger > > libthread_db related loading / initialization in GDB. It's possible that > > there may be a better way to do it though.) > > Hmm, although if libpthread.so is still there, even is mostly empty, it > can still be used by GDB as a trigger to load libthread_db: > > - libc.so gets loaded, we don't try to load libthread_db > - The mostly empty libpthread.so gets loaded, so we try to load > libthread_db. libthread_db requests a bunch of symbols. These > symbols are found, because they are in libc, which is already loaded. > > Is the long term plan to completely get rid of libpthread.so, or is it > going to stay as this mostly empty library? If it is going away, then I > agree we have to change the way we trigger the load of libthread_db. Fedora 34 / glibc-2.33.9000: [kev@f34-2 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls linux-vdso.so.1 (0x00007ffcf94fa000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007ff0ba9af000) libm.so.6 => /lib64/libm.so.6 (0x00007ff0ba8d4000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007ff0ba8b9000) libc.so.6 => /lib64/libc.so.6 (0x00007ff0ba6c6000) /lib64/ld-linux-x86-64.so.2 (0x00007ff0babf0000) Fedora 34 / glibc-2.33: [kev@f34-1 gdb]$ ldd testsuite/outputs/gdb.threads/tls/tls linux-vdso.so.1 (0x00007fff32dc0000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f815f6de000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f815f4bf000) libm.so.6 => /lib64/libm.so.6 (0x00007f815f37b000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f815f360000) libc.so.6 => /lib64/libc.so.6 (0x00007f815f191000) /lib64/ld-linux-x86-64.so.2 (0x00007f815f721000) Note that libpthread is missing from the ldd output for the glibc-2.33.9000 machine. I'll post my patch soon... Kevin