From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) by sourceware.org (Postfix) with ESMTPS id 7612B3846411; Fri, 16 Apr 2021 16:33:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7612B3846411 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f49.google.com with SMTP id k26so10859869wrc.8; Fri, 16 Apr 2021 09:33: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=vHe9oSw5QVpxruGwGfqevCxvTMgzSnGRluUD0IPVCTY=; b=PTCm9Z7l3r18WTxSLHkTD7c3SzZ2bilJkAvyBWh9pI6hDpSBCVYLagXSZlHdG1qSEt nDJATJ4mSl1h7DB7xGhfQr2nNL23okdVNBX7cBuy6KjnZAXR+99W4ZGApsOup9Z1+vOG JdVvdW7OQUUxZIli7l/eChlzMdG3X3bUY3se1Eg3wGIoOX6oY1nMHv9r7yc2F5LagHNC kuMrpKxHuK464oy1KrR563g0c6b0VkmB/TeteIuHzH5jB9LWFmQFki/kaIq6wSDGpX5R pxR5FYJzOZgOOTnIesRGK3m21cLUhsStucIjgiBczEIWaqZKYQ9y56PlS634rtNiVLbu WjOg== X-Gm-Message-State: AOAM530nOEvSwY2/vzK6xp6gX1o6JI+pOX+LwyC2rj/nfnVia8Tzufod XWjHQDCvVqtk5jAbVNZqd3o= X-Google-Smtp-Source: ABdhPJy61leU+RY+67IONziNFoSQzOU4eXG12Zz6TUWJKN99hUn3/UuZnXDgbrE3PGo+EACaWM7BaQ== X-Received: by 2002:adf:e607:: with SMTP id p7mr16260wrm.381.1618590797316; Fri, 16 Apr 2021 09:33:17 -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 j6sm9484884wmq.16.2021.04.16.09.33.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 09:33:16 -0700 (PDT) Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) From: Pedro Alves To: Florian Weimer Cc: Simon Marchi , libc-alpha@sourceware.org, gdb-patches@sourceware.org, Emil Velikov , Kevin Buettner References: <87sg3qnrz3.fsf@oldenburg.str.redhat.com> <73b32cc6-e201-8bac-e442-e3dddcc01e0d@polymtl.ca> <625ec5fe-bd09-860a-f617-745042b94011@redhat.com> <87fszqnqi3.fsf@oldenburg.str.redhat.com> Message-ID: Date: Fri, 16 Apr 2021 17:33:14 +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: <87fszqnqi3.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP 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: 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:33:22 -0000 On 16/04/21 17:28, Florian Weimer wrote: > * Pedro Alves: > >> 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? > > Yes, I believe this is what happens. > OK, I believe what is confusing in your commit log was the reference to two different kinds of "loaded": "libthread_db is loaded once GDB encounters libpthread, and at this point, ld.so may not have been loaded yet. " The first loaded is about GDB dlopening libthread_db.so. The second loaded refers to reading symbols -- ld.so has been loaded by the inferior already at that point. It would be clearer as: "libthread_db is loaded once GDB encounters libpthread, and at this point, ld.so's symbols may not have been read by GDB yet. " If I understood that correctly, then the following sentence is also a bit confusing: "As a result, _rtld_global cannot be accessed by regular means from libthread_db." Because that sounds to me like you were perhaps talking about some magic means to reference globals, some magic relocations, or some other magic voodoo only understood by glibc experts. Pedro Alves > I assume that ldd shows objects in link map order, the it looks like > this: > > $ ldd /usr/bin/python3 > linux-vdso.so.1 (0x00007fff1f8d5000) > libpython3.9.so.1.0 => /lib64/libpython3.9.so.1.0 (0x00007f3fd7782000) > libc.so.6 => /lib64/libc.so.6 (0x00007f3fd75b7000) > libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3fd7595000) > libdl.so.2 => /lib64/libdl.so.2 (0x00007f3fd758e000) > libutil.so.1 => /lib64/libutil.so.1 (0x00007f3fd7589000) > libm.so.6 => /lib64/libm.so.6 (0x00007f3fd7443000) > /lib64/ld-linux-x86-64.so.2 (0x00007f3fd7af7000) > > Thanks, > Florian >