From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 5291 invoked from network); 21 May 2020 20:41:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 May 2020 20:41:03 -0000 Received: (qmail 24016 invoked by uid 550); 21 May 2020 20:41:02 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 23998 invoked from network); 21 May 2020 20:41:01 -0000 Date: Thu, 21 May 2020 16:40:49 -0400 From: Rich Felker To: Harald Welte Cc: musl@lists.openwall.com Message-ID: <20200521204048.GJ1079@brightrain.aerifal.cx> References: <20200521202253.GC601762@nataraja> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521202253.GC601762@nataraja> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] MUSL ignores__attribute__((constructor(priority))) ? On Thu, May 21, 2020 at 10:22:53PM +0200, Harald Welte wrote: > Hi all! > > While investigating some really strange behavior of osmocom software > on MUSL based systems (see https://osmocom.org/issues/4456) > there are two observations: > > 1) if there are multiple libraries (in this example libosmocore and libtalloc, > where libosmocore depends on libtalloc), the __attribute__((constructor)) > functions are not called in inverse dependency order, i.e. the talloc > ones are *not* called before those of libosmocore. They should be, since commit 188759bbee057aa94db2bbb7cf7f5855f3b9ab53 (releases 1.1.22 and later). Are you using an older version? > 2) even when adding an explicit "priority" field like > static __attribute__((constructor(65535))) void on_dso_load_ctx(void) > the MUSL ld.so doesnt' seem to respect this, i.e. it still calls the > constructor with the high priority value *before* the constructor of lower > priority. This is not as specified in https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Function-Attributes.html > > I don't know whether '1' is a bug (i.e. whether it is valid to assume constructors > of libraries are executed in-line with library dependencies). However, I am > quite convinced '2' is a bug. The scope of ctor priorities is within a single DSO. Priorities are used by the linker to order them within the ctor array of the library. They are not exported for dynamic linker to use, and trying to interleave the calling of individual ctors/dtors between different libraries would be really problematic I think. In general, if you have specific order dependencies between ctors, the best way to express that is with explicit calls from one library's init function to the other using call_once/pthread_once. This is fully portable and does not depend on implementation details. > p.s.: Please keep me in Cc, I'm not a subscriber to this list. Will do. Thanks for mentioning it. Rich