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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 4DF4F3857C68 for ; Fri, 4 Jun 2021 22:42:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4DF4F3857C68 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-557-Wwx048BHOn-fzg-nplZgGA-1; Fri, 04 Jun 2021 18:42:11 -0400 X-MC-Unique: Wwx048BHOn-fzg-nplZgGA-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DBEFB800D62; Fri, 4 Jun 2021 22:42:10 +0000 (UTC) Received: from f33-m1.lan (ovpn-112-83.phx2.redhat.com [10.3.112.83]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 660715D6D1; Fri, 4 Jun 2021 22:42:07 +0000 (UTC) Date: Fri, 4 Jun 2021 15:42:06 -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: <20210604154206.7f8d48f3@f33-m1.lan> In-Reply-To: <20210504180245.3020757-1-simon.marchi@polymtl.ca> References: <20210330172149.1724381-1-simon.marchi@polymtl.ca> <20210504180245.3020757-1-simon.marchi@polymtl.ca> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 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=-6.7 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 autolearn=ham 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: Fri, 04 Jun 2021 22:42:15 -0000 On Tue, 4 May 2021 14:02:45 -0400 Simon Marchi wrote: > Since I wrote this patch, Florian Weimer merged this in glibc that > mitigates the issue: > > https://sourceware.org/git/?p=glibc.git;a=commit;h=a64afc225240b2b27129ccfb0516d7c958b98040 > > But his commit message notes that it's "To make this work until GDB can > be fixed", so we might also want to fix this on the GDB side. Also, the > patch can be desirable even if just the performance / waste less cycles > aspect. > > Compared to v1, v2 uses a dedicated inferior flag instead of trying to > re-use needs_setup. It also makes things work with the extended-remote > target. Florian has provided me with packages for glibc-2.33.9000, which is a test release for glibc-2.34. One of the really big changes in 2.34 that affects GDB is that libpthread is largely empty now; when I examined it, I found that it contained some versioning symbols and little else. E.g... 0000000000000000 g DO *ABS* 0000000000000000 GLIBC_2.3.3 GLIBC_2.3.3 0000000000000000 g DO *ABS* 0000000000000000 GLIBC_2.3.4 GLIBC_2.3.4 0000000000001110 g DF .text 0000000000000005 (GLIBC_2.28) __libpthread_version_placeholder (These aren't all of the symbols, just a sample. But nearly all of them are like the ones shown here.) The important stuff that used to be contained in libpthread has been moved to libc. E.g. pthread_join is now found alongside execvp in libc-2.33.9000.so... 000000000008c1c0 g DF .text 0000000000000013 GLIBC_2.34 pthread_join 000000000008c1c0 g DF .text 0000000000000013 (GLIBC_2.2.5) pthread_join 00000000000d9dd0 g DF .text 0000000000000013 GLIBC_2.2.5 execvp I've tested your patch on a Fedora 34 machine updated to use glibc-2.33.9000 and have found that your patch is necessary to avoid lots of failures in (e.g.) gdb.threads/attach-many-short-lived-threads.exp. Without your patch, I see 79 passes and 30 failures for this test. With your patch, we get the expected 109 passes. 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.) I've looked over your patch and am happy with the approach that you've taken. I think it should go in. Kevin