From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13726 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: dlsym(handle) may search in unrelated libraries Date: Thu, 7 Feb 2019 21:31:38 +0100 Message-ID: <20190207203138.GG5469@voyager> References: <20190206160248.GB5469@voyager> <20190206202518.GC5469@voyager> <96c367533236e3e203f04a994ee65c47@ispras.ru> <20190207053327.GD5469@voyager> <20190207165447.GP23599@brightrain.aerifal.cx> <20190207183637.GF5469@voyager> <20190207185736.GR23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="68592"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13742-gllmg-musl=m.gmane.org@lists.openwall.com Thu Feb 07 21:32:44 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1grqLk-000Hh6-Iz for gllmg-musl@m.gmane.org; Thu, 07 Feb 2019 21:32:44 +0100 Original-Received: (qmail 15956 invoked by uid 550); 7 Feb 2019 20:32:41 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 15935 invoked from network); 7 Feb 2019 20:32:41 -0000 Content-Disposition: inline In-Reply-To: <20190207185736.GR23599@brightrain.aerifal.cx> X-Provags-ID: V03:K1:juo2nKJ0yoohJe1iPjXvWhfcDVoDwv/eSR7md6xnUx3eoqkaPKT bB1hFWY+2md14mfvOHG8OJZKLqAIFbgQHUd6vLRy1SjsWuez6THSaUkWZn1wlGX32nY8me0 QuK5/Gs3lkkihJJdP6ZXIxoOu5yggClHcvzOo/fIvar48F4766/TT09b07RIK9SP10tZMi8 jUl/ybBCzBylPpl2U32dA== X-UI-Out-Filterresults: notjunk:1;V03:K0:FeSjJqloBQA=:o67LThUqfAJEwe9HsLp3zL 9R5B3MaRVOnSz3jflmn1raKHMluxpV+FwIQ7QnVWi03LVlL1HsJoGSM/zncLPY1zRFG2prwlY ln7khxZLItFkMmzwL2XGphM3Srysz7YSI7cpFLM7MA3wMwUY1d0yfCzx8WvKWsnxnFC9YsnMl VQlrHDtsbDP9zPl1/NB0b1dGXMjZOj7jhiUHK3KhSvkwetuqjEFrL7IgjaKixKSDs+EE0yEAu GJ+iInqBunOBgegxK71MOVxU7yXfXx8Iw0hBxI13Z5hdkPfa66YPlb8zx4gPdnoVRVI6HhpmL fNx9fylL7dRiY+LJvfIPBHrrYfSf9xIQq4Mjs3GIp36+Tz+IBTQ73/NsEcjEwvG6Xzq44pRhi 2eTy1wqpALX48PCq5ib4m7sq1EkJo7wGADf+HISAoS0EZtwS+OzyhDH9M5Z4DIIMNkg0T54xb vmtF2CGWpZOydV1Vtxyta3Wj+VGwmWqIUoGqXK8xPpCtMOYDaJHS7l5nHlK93nCPkiUhAFy2J c/gtYb5zrz8McimV8stxuWjL+Mo3ysFWJM19VcWMbTzoByqdSmbo1fs+02D7g772Suk78w4xW j3AZpaBiLjhHSjMjXiseZkitxMzk6n0Hd6atZYuPnhIdJSbfbQThLSeod1aJoRS4eGWLuCHEz 7F5WTCnLrPJbtpCCr6Fyu0w3qYmJyu38Nfbro08oKckJTn6JXtjASw4DX+ED1U4CO/xziYmtB pPucIu+ptVfG76Qj64P8IRYZgcmxMtHNDvtStV+pdi+ar7hi+R2qjpaksA2q4dm7o48A1ugw Xref: news.gmane.org gmane.linux.lib.musl.general:13726 Archived-At: On Thu, Feb 07, 2019 at 01:57:36PM -0500, Rich Felker wrote: > Yes. GCC has an extension for ctor priority within static linking > scope, but for dynamic linking scope that doesn't help. I don't like > any of this but glib depends on it to avoid just doing the right thing > with pthread_once/call_once, and refuses to fix it. > Well, at least we are on the same page, here. And my opinion of glib is validated once more. Unfortunately, at this point it is too big to fail, in several ways. > Yes, but you can also avoid recursion just by looping to the deepest > dependency with !inited, then going back to the root. For a one-time > operation at dlopen-time or program-start time, the quadratic search > for each !inited seems unlikely to be a problem: > Wait, I have an idea. If the only ordering is that the dependencies need to be initialized before their dependents, then couldn't we just initialize the libs in reverse BFS order? The elements further down the tree are all necessarily further down the list, aren't they? > I don't follow. The dlopen operation is not committed until load of > all dependencies completes successfully, and if any fail to load, the > whole operation is backed-out. But ctors don't/can't run until *after* > that, when we've already committed to success. > That is true for the runtime case, i.e. dlopen(). But load_deps() is also called at load time. And initializers have to run at load time, too. And in the correct order. If at load time, any dependencies fail to load, an error message is printed and then the loop continues. load_deps() has no way to signal failure to the caller, and at load time it will not exit the function in another way, i.e. longjump (which is good since that would be invalid at that time). So by the time the initializers are called, all dependencies are loaded except those which failed. > Rich Ciao, Markus