public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeffrey Walton <noloader@gmail.com>
To: "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Subject: Method to specify initialization order across translation units?
Date: Wed, 05 Aug 2015 16:47:00 -0000	[thread overview]
Message-ID: <CAH8yC8kTWOkN2iuuWt1gg6xNqHpVSVz7ZKLqnC6N1D9p1z6k=w@mail.gmail.com> (raw)

I'm catching an intermittent failure due to initialization order
across translation units. The code is for a C++ library that offers
both a static archive and a shared object.

My first thought was to provide an accessor function and make the
global a static local. That did not work because the order of
construction and destruction was not right. It resulted in a crash in
a destructor because an object disappeared too soon. My second thought
was init_priotrity and __attribute__ (constructor) (and friends), but
I know from experience that does not work across translation units.

My third though was a linker script, and then I came across "Replace
.ctors/.dtors with .init_array/.fini_array on targets supporting them"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770#c96) and "collect2
breaks link order control"
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53068). If I am reading
the reports correctly, then a linker script is not the tool for the
job.

We also thought about adding a global.cpp file, but we are not sure it
will meet goals because of third party programs, the static archive,
and the interactions during linking.

The static archive seems to be the trickiest case because of the
interaction with third party programs. The shared object seems to be
an easier problem because its fully linked, and does not interact with
program linking. (Open question: does LTO affect this?).

Are there any methods to specify initialization order across
translation units? If so, what is it (or are they)?

             reply	other threads:[~2015-08-05 16:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-05 16:47 Jeffrey Walton [this message]
2015-08-05 20:50 ` Andrew Haley
2015-08-12 21:48   ` Jeffrey Walton
2015-08-13  8:05     ` Jonathan Wakely
2015-08-14  0:00       ` Jeffrey Walton

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='CAH8yC8kTWOkN2iuuWt1gg6xNqHpVSVz7ZKLqnC6N1D9p1z6k=w@mail.gmail.com' \
    --to=noloader@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).