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-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D00601F731 for ; Mon, 5 Aug 2019 10:45:46 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; q=dns; s=default; b=EVEqR Ry/p45ZKO97UWSImNrf8siUm0JYIu9cKvovpto3ZCBnC/bGSMCnRrp4dfTBVFupx uZCBO/hvBKoEF1dGhSAQ05VQupxYuVwjabb6UDmkoakErS6t9M1Of+Smgxgd8j14 97olvefAiTrF4/hVLCVstMtgY8Jys/vIMs1ATo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:cc:subject:references:date:in-reply-to :message-id:mime-version:content-type; s=default; bh=g7nKVGrU54q cPywAlLSw943lL0Q=; b=bXv5YSzA6oXx95+xmLmA15tXjko5UpyAs2OLUcXUqBk AEFS1M1pUuBc4e0ds462cmyYpfSGSJOREGJ577ka2f5+AGQkjcWOD2pbEoOVbvGK K8aZ7963s8veaWao4gxANyxL7Qv3uFSQ/6TQrimWcYQ/pRCPaO7JIEwSfJoURl0A = Received: (qmail 48452 invoked by alias); 5 Aug 2019 10:45:44 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 48442 invoked by uid 89); 5 Aug 2019 10:45:44 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com From: Florian Weimer To: Chung-Lin Tang Cc: , GNU C Library Subject: Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader References: <87h87crimv.fsf@oldenburg2.str.redhat.com> <87wog15fyy.fsf@oldenburg2.str.redhat.com> Date: Mon, 05 Aug 2019 12:45:40 +0200 In-Reply-To: (Chung-Lin Tang's message of "Mon, 5 Aug 2019 18:39:07 +0800") Message-ID: <87mugnao17.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain * Chung-Lin Tang: > On 2019/7/29 5:48 PM, Florian Weimer wrote: >> * Chung-Lin Tang: > >>>> Can your test framework test both cases? What's your position on the >>>> second effect? I think it sometimes results in destructors running not >>>> in the opposite order of constructors, due to the new topological sort. >>>> (This also happens with the current implementation.) >>> >>> What I did in the ld.so code patch was add a second pass of sorting >>> that ignores runtime deps, prioritizing link dependencies; this >>> appears to also be what prior discussion pointed towards, see more >>> details in that 2nd email with the actual code patch. >> >> I wonder if it makes sense to disentangle this (desirable) functional >> change from the rest (which sould be purely an optimization). > > By "functional change" here, are you referring to the testing framework, > or the described ld.so destructor behavior I described above? The destructor behavior. >> Is it even necessary to re-sort on dlclose? Is the original dependency >> order available somewhere? Then we could make it explicit that the >> destructor order is the reverse of the constructor order (for the >> objects unloaded). Or is there a corner case which causes an expected >> divergence? > > Dynamic loaded objects could add more relocation dependencies, and > thus augment the dependency relations (by adding more constraints), so > a final sort should still be required. Yes, these dynamically added relocation dependencies could mean that fewer objects than had been loaded by the dlopen can be freed with dlclose. But if we disregard those relocation dependencies for destructor order sorting, wouldn't be the sorted result equivalent to the constructor order? Thanks, Florian