[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200521204048.GJ1079@brightrain.aerifal.cx>
Date: Thu, 21 May 2020 16:40:49 -0400
From: Rich Felker <dalias@...c.org>
To: Harald Welte <laforge@...monks.org>
Cc: musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
