From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by sourceware.org (Postfix) with ESMTPS id 3164A3893644; Fri, 16 Apr 2021 17:18:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3164A3893644 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-wm1-f43.google.com with SMTP id w7-20020a1cdf070000b0290125f388fb34so14460559wmg.0; Fri, 16 Apr 2021 10:18:28 -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=+tKG1R5QyWC01tSFXtg9BHOvrarY8mpgC/5yprDNMJs=; b=QfJnA9hLL5zo/nF6b9AeHBtOG+PaUZ7sEgn8NiURJVDSL5u/5VFKxphCBOI1JYfGwG rrc6z9cIz6g2Nh1+MjcQHf/u/l9x74Sb0/USRdX2EiKWJ7dCurpX8H8eixc44vw36u4n ZJJ0Tb4iFWo4jPe62WYGWnzQ4xgBN4o+68t+SsKdNMdWNM68lUhk7eMhVEuL6uQIaa26 VX9/p04+XVSNnQecos8mFf3vO/0wrcb1dg9SoLwD/tzXxOJv3Z8mddhLznjLNSRoCNxJ NwGlDd/tUwJAp1VtI5atFL4e2NPy5Ro4e+7Lwwwq2ArweQ+sjF+LeOEBhExm6+lV50bo 1Prw== X-Gm-Message-State: AOAM532Q4M7Kj7an9QG6CcAi/jY4EV7TbmQAidKh8BFvEWvIdqqA4X9g FOmehsDazsb+6uYTUzNPxCpYJml65CQbWg== X-Google-Smtp-Source: ABdhPJwr66EjIBwpCVdEPal3NG+sb0Ablf0OfnM6LMgZh1G2POcWAqsBeX/xBwCKRr9PqlRWWOSdfA== X-Received: by 2002:a1c:9dd1:: with SMTP id g200mr9447380wme.60.1618593507201; Fri, 16 Apr 2021 10:18:27 -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 r11sm3771854wrx.22.2021.04.16.10.18.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Apr 2021 10:18:26 -0700 (PDT) Subject: Re: [PATCH glibc] nptl_db: different libpthread/ld.so load orders (bug 27744) From: Pedro Alves To: Simon Marchi , Florian Weimer Cc: 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> <87blaenprw.fsf@oldenburg.str.redhat.com> <83364527-b4aa-b7cc-928b-10d20c4338a3@polymtl.ca> Message-ID: Date: Fri, 16 Apr 2021 18:18:24 +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: <83364527-b4aa-b7cc-928b-10d20c4338a3@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 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 17:18:38 -0000 On 16/04/21 17:53, Simon Marchi wrote: > Do we need / want to fix GDB if this goes in glibc then? I think so. We may need to discuss more the "needs_setup" hack, but we can do that in that thread. Given that libpthread.so is going away in the future, we should be thinking about addressing that as well. Does your patch fix that as side effect? If not, GDB should be keying the loading of libthread_db.so on something else. Making GDB try to load libthread_db in reaction to processing ld.so instead libthread_db.so would fix that, I think. And, it would fix this ordering problem at hand as well. So if we do that, maybe we don't need the other changes. > I have an > updated version of my patch here [1] sitting here, that makes it work > with GDBserver as well, with the "broken" glibc 2.33. I'm wondering if > I should post it or not. > > Even without this bug, my patch can be beneficial from an efficiency > point of view, since it delays sending a qSymbol to the remote side > until all shared libraries are known. Right, I like batching for this reason. > But then it would be a completely > different rationale, I would have to word the commit message in terms of > "make things more efficient" rather than "fix a bug while attaching". >