mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Harald Welte <laforge@gnumonks.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] MUSL ignores__attribute__((constructor(priority))) ?
Date: Thu, 21 May 2020 16:40:49 -0400	[thread overview]
Message-ID: <20200521204048.GJ1079@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200521202253.GC601762@nataraja>

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

  reply	other threads:[~2020-05-21 20:41 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21 20:22 Harald Welte
2020-05-21 20:40 ` Rich Felker [this message]
2020-05-21 21:19   ` Harald Welte
2020-05-21 21:49     ` Rich Felker
2020-05-22 16:50       ` Harald Welte
2020-05-22 17:33         ` Rich Felker
2020-05-22 17:45           ` Hauke Mehrtens
2020-05-22 17:53             ` Rich Felker
2020-05-22 23:37               ` Alexander 'lynxis' Couzens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200521204048.GJ1079@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=laforge@gnumonks.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).