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 84D123844041 for ; Fri, 16 Apr 2021 16:25:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 84D123844041 Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-271-AcNR7z9HMtydSFuME0qs6A-1; Fri, 16 Apr 2021 12:25:18 -0400 X-MC-Unique: AcNR7z9HMtydSFuME0qs6A-1 Received: by mail-wr1-f72.google.com with SMTP id j16-20020adfd2100000b02901022328749eso4671870wrh.4 for ; Fri, 16 Apr 2021 09:25:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Fpa036qu4TIsVUA1fFGIB/xLajiIeALjoUsgJeraL1I=; b=TAjGO5wtxo2FS4v2jyIrn6Qsr00oj2q7jE3v/0H84Ym0rad7IF704/RQezhQnpKq87 H4qZe33Xr0I63Y59NlWSBAUdupTJB1DXsY0IRziR1BURbDPT/O4HbvUr0GHXF1DZG1cI u+lwYcqOAU47CmNF7CFKvb2KrnidjrEAs3gnHcvGCmvUu2upbBT8w8xuHD5TgDS6OD2b BbhQMdZhE9IgxaTE8uoa1no7kR5LShT/1EkpN9vPKZC3zOkzZAsQ7SOhl9MSIvezzXwX XTtTBbtKH6NIq7jOLZ3TNDhh641nMa32rbvbdCLGUMoYOgdBI/LNhnXj8xHPRqa7BFo3 dIaA== X-Gm-Message-State: AOAM531+hEKeoNQzLr8HF4CuI33EZEKvCWQDOJoYgpnH7Opu7FBIKHTz uF+O8I7RkoCqx5N3O22aBm/0cQ3L3RvL9I7q10vgHuex8qZJQun/BHW62vvRj//AxMHYZCv6enG /o1QK1ZCqZYH/q9wGtHX8 X-Received: by 2002:adf:a40c:: with SMTP id d12mr1417wra.91.1618590316872; Fri, 16 Apr 2021 09:25:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx/qcAJTGQyEjU16lAyH3pe1wMVB/WZVFEcWLoTHzO+EuIVUEVqce0oduXT2zN4J3vwiVsVMw== X-Received: by 2002:adf:a40c:: with SMTP id d12mr1405wra.91.1618590316752; Fri, 16 Apr 2021 09:25:16 -0700 (PDT) Received: from ?IPv6:2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3? ([2001:8a0:f932:6a00:6b6e:c7b6:c5a7:aac3]) by smtp.gmail.com with ESMTPSA id n9sm9420828wmo.27.2021.04.16.09.25.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 09:25:16 -0700 (PDT) Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) From: Pedro Alves To: Simon Marchi , Florian Weimer , libc-alpha@sourceware.org, gdb-patches@sourceware.org Cc: Emil Velikov , Kevin Buettner References: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> Message-ID: <625ec5fe-bd09-860a-f617-745042b94011@redhat.com> Date: Fri, 16 Apr 2021 17:25:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, 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: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2021 16:25:22 -0000 On 16/04/21 17:07, Simon Marchi wrote: > > 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 don't think it's random from GDB's perspective -- GDB reads the shared library list of out of the link map, so it should be reading them in link map order. IIRC, the order which libraries are loaded by GDB hasn't changed. The issue is that until recently (before glibc 1daccf403b1b), the stacks lists lived in libpthread (stack_used/__stack_user), so the fact that GDB loaded libthread_db.so before ld.so's symbols were loaded didn't make a difference. Now they were moved to ld.so, so libthread_db.so can't find them until GDB reads the ld.so symbols. Is this assessment correct? Pedro Alves