From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.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 (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 166821F5AE for ; Mon, 27 Jul 2020 10:00:57 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 488893857C6A; Mon, 27 Jul 2020 10:00:56 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 789B83858D35 for ; Mon, 27 Jul 2020 10:00:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 789B83858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ChungLin_Tang@mentor.com IronPort-SDR: SbQGlByJufyv62JHy4St8ieZUbHA4Xe3Kvq3VnDrrq14mTG0LOB2z22Do1fDymN1W8lsokpmZ5 uJdaaTLvaCPbWpivAd7gSXTGVBC0kV3zL6Kw711OWDulpp+vmmDuyyi2XbCkY/7ImFflql9a/P y0kH9kQ8xrLNdaYPg8/Q+TnaWP9mqbl+cIQT0Ave7IpTQyclCJvybewIDssroePEImeEpfKR8H mlMui37S83TkSf5NQm/tsFERhhSaY5wi9/8x0VHDYGPdVjp7LMuQtjWsb+/dXImT1hsnPRuO0i LQo= X-IronPort-AV: E=Sophos;i="5.75,402,1589270400"; d="scan'208";a="51327536" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 27 Jul 2020 02:00:51 -0800 IronPort-SDR: 3svuxoqGx0GvXW/UjD0cV8Tf5aDyASInBaV59R4vb1qvVvO/CdEDoy7COb5kmiwfkviC6hohow k6mQW21DsC9KXHdWCl4zaG5XrBuBzoMHNGCP0rkTYFMaxb7KYap9ClyzvyPkmAYc5PY1ppUJGK KaM/zzAxKE6FsukODbxTTqmr6KUnjFuxVyhSltsDT/grnpF6uBiiUOcgdcxBuiyq7rlqsRKsxm 2e3oPMLeYQv1A4W/xXFisSaqegG4HCU2IYmSG2oRm+M5e/5C7ffkx4R5CnGiSVF++UuP87dEDz 9Hk= Subject: Re: [PATCH v3 1/2] BZ #17645, fix slow DSO sorting behavior in dynamic loader To: Carlos O'Donell , Andreas Schwab References: <87a724uhtf.fsf@igel.home> <87tv0ct1vl.fsf@igel.home> <456fbddc-7915-19da-3ffe-e58b86ae7980@redhat.com> <1427b370-7400-afd0-16e8-55c1072db20e@mentor.com> From: Chung-Lin Tang Message-ID: <47d5d0a3-4e55-d915-8ced-6ad0c68d6aaf@codesourcery.com> Date: Mon, 27 Jul 2020 18:00:21 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SVR-ORW-MBX-06.mgc.mentorg.com (147.34.90.206) To svr-orw-mbx-02.mgc.mentorg.com (147.34.90.202) 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: , Cc: Catherine Moore , GNU C Library Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On 2020/7/27 8:40 AM, Carlos O'Donell wrote: > On 7/22/20 2:10 PM, Chung-Lin Tang wrote: >> I only now notice that "permute" vs "permutate" is an issue :) I've corrected the >> spelling as you've suggested. >> >> The v3 patch is attached, please see if this is now okay for committing. > > I'm going to review this shortly, but it's too late in the release to add it to 2.32. Sigh, okay. I respect the release manager's decision. > My plan, if you agree, is as follows: > > (a) Review this promptly this week. > (b) Switch the sense of the default to just use the new DFS sort. > (c) Open 2.33 for development and commit the changes. > (d) Sync Fedora Rawhide and spend the next 5 months testing this in Rawhide. Thanks, I assume this means I'm (mostly) approved to commit soon after 2.33 development opens. > There are still a few more changes we need to make in the test generation, > for example the tests don't use support/test-driver.c which means they could > hang the entire testsuite and they don't support timeouts because of this. > > We should follow generating the test such that the executable uses test-drive.c > like all new tests should. This way we can catch tests that used to take 200s > and now take 1s (default timeout at 20s). I understand the need to support timeouts, but actually, because of the nature of the ld.so sorting tests, where a lot of the action happens before/after main(), making the testcase executables use support/test-driver.c isn't really that meaningful. In terms of the relations, you would need to wrap the entire ld.so into a testcase for that to work. Do we already have some support program that embeds support/test-driver.c (like a testcase) and allows forking of a generic program + command-line? That should allow running the entire ld.so with a timeout I suppose. Another method would be to do something in the generated shell script wrapper to implement a timeout. Thanks, Chung-Lin