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 60DCE1F462 for ; Mon, 29 Jul 2019 09:48:42 +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=GIuY4 EQ2OnDSxaxr0ot/LV15ZsQZwbuWjBpmV5OWdjAffgwMFElna0KfQFA9z6b7Jmj0T rSOFwLsDjSIN0+hG207EVxTmGQm8nkgidnCq1mBEv6Xdns1aKKThl7dZeHAyFWTs wq68qOeROyEtbYJfAlXQXcxgap+PHx305IKBQ4= 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=yNZY/cC2kej jXK5tZrfFrzxqNlA=; b=UXXZgsEtHDUDkYLPPPuzzzJje6YDwA7uC0AyxywNlM2 Vlq1GOGAcVdANW5nCpYvaEthWQ7M/xfke3/aqmxSD0l8j0an8n0h+rBKyY2JVP5j /lmQWpMr/kWF6tyWPpa3NpXR3F21lwZcDFv46OHORHBLU153wb9ogo6iXfIw8u6M = Received: (qmail 97843 invoked by alias); 29 Jul 2019 09:48:39 -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 97700 invoked by uid 89); 29 Jul 2019 09:48:27 -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> Date: Mon, 29 Jul 2019 11:48:21 +0200 In-Reply-To: (Chung-Lin Tang's message of "Fri, 26 Jul 2019 02:46:15 +0800") Message-ID: <87wog15fyy.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/23 9:21 PM, Florian Weimer wrote: >> Is => intended to cover the case of run-time dependencies added late due >> to lazy binding? >> >> Currently, those late dependencies have two effects, I think: They keep >> around the referenced libraries longer than before (so that dlclose >> would not remove an object which is still in used solely due to lazy >> binding). And the ELF destructors are reordered to reflect these added >> run-time dependencies. > > Yes, you can test that. The effect of => is to create a caller/callee > relation between objects: 'x=>y' creates fn_x() and fn_y() in those > two DSOs, and fn_x() has a call to fn_y(). > > Though that's the only immediate effect that => has. To construct a > test of run-time added dependencies related to dlopen/etc. you also > need to add those operations inside the '{}' construct. > > All the created DSOs have a constructor/destructor that outputs their > single character name. The generated main() program prints '[]' > brackets after dlopen/dlclose calls to separate out the following > constructor/destructor output. So taken whole, the entire output > string should capture all constructor/destructor activity and ordering > behavior. I see, thanks. >> 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). 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? Thanks, Florian