From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wNcJCYq3eWD6FgAAWB0awg (envelope-from ) for ; Fri, 16 Apr 2021 12:12:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 230041F104; Fri, 16 Apr 2021 12:12:58 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 40D231E813 for ; Fri, 16 Apr 2021 12:12:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BE9903893649; Fri, 16 Apr 2021 16:12:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE9903893649 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1618589576; bh=jDfm/5l/peTToXnOojajLiUH1kUInmgPpbu1MsEVEuI=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=UHwdiVKd/X5NA+RwRzJ8FEe58tt3uT8zlF6vZB340CeIcj1sc+6MmgS5x/7qPf7PC G4njhLCIy0Cy6GP99aZ4BR4dRG7VfhLhxgy4Q6TTAmPA5nv3/n50+ALDyibYfAd6C2 eM+fqi8DtdPJx5U6/e3tvehap5JsJE2c83B+UZAs= 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 0604F38930C7 for ; Fri, 16 Apr 2021 16:12:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0604F38930C7 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-1-IYHrbGXUN7Ck-633D_8VtQ-1; Fri, 16 Apr 2021 12:12:44 -0400 X-MC-Unique: IYHrbGXUN7Ck-633D_8VtQ-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 89843100A25C; Fri, 16 Apr 2021 16:12:42 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-113-139.ams2.redhat.com [10.36.113.139]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E62F15D9E3; Fri, 16 Apr 2021 16:12:40 +0000 (UTC) To: Simon Marchi Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) References: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> Date: Fri, 16 Apr 2021 18:12:58 +0200 In-Reply-To: <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> (Simon Marchi's message of "Fri, 16 Apr 2021 12:07:53 -0400") Message-ID: <87k0p2nr79.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) 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 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: , From: Florian Weimer via Gdb-patches Reply-To: Florian Weimer Cc: Emil Velikov , libc-alpha@sourceware.org, gdb-patches@sourceware.org, Pedro Alves Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" * Simon Marchi: > On 2021-04-16 11:56 a.m., Florian Weimer wrote: >> libthread_db is loaded once GDB encounters libpthread, and at this >> point, ld.so may not have been loaded yet. > Can this state (libpthread loaded, ld.so not loaded) really happen > during the normal lifetime of a process? My understanding is that this > state happens when attaching only because GDB reads the shared libraries > from the process in an undefined order, so libpthread may be discovered > before ld.so. So we present to libthread_db a state that doesn't really > make sense. I think it depends on the order of the link map list, I think, and there ld.so ends up being sorted last. If libpthread gets merged into libc for glibc 2.34, I will try to make this work with old GDB by adding a fake libpthread.so.0 at the end of the link map list, after ld.so. But none of this code exists yet, so it's impossible to know if it actually will work as expected. Thanks, Florian