From: Craig Southeren <craigs@postincrement.com>
To: binutils@sourceware.org
Subject: Re: PATCH: PR ld/12730: regression] crash when allocating in a static constructor
Date: Sun, 15 May 2011 10:14:00 -0000 [thread overview]
Message-ID: <4DCFA77B.9060300@postincrement.com> (raw)
------------------------------------------------------------------------
> On Mon, May 9, 2011 at 6:53 AM, Alan Modra<amodra@gmail.com> wrote:
> > I'm starting to wonder whether ld/testsuite/ld-elf/pr12730.cc is
> > valid. ?Does gcc actually make any guarantee about order of static
> > constructors and __attribute ((constructor)) functions?
>
> I have similar doubt.
>
> > Compiled with gcc-4.3 branch g++, the testcase segfaults at all
> > optimization levels. ?Compiled with gcc-4.4 branch g++, the testcase
> > runs at -O0 but segfaults at -O1 and above. ?It happens to run OK with
> > gcc mainline and 4.6. ?Given that behaviour, and the fact that some
> > popular distros ship gcc-4.4 based compilers, I'm thinking that the
> > testcase should be removed.
> >
>
> I will do that.
>
At the heart of the issue is the timing of initialising statics at the
global/namespace level. Prior to the recent change, these statics were
initialised the first time that any code from the enclosing translation
unit was executed. Now, it appears that all such statics in all
translation units are instantiated at start-up.
As the order of statics the global/namespace level is not strictly
defined, the new implementation is probably compliant. However, this
choice means that global/namespace statics do not have the same kind of
behaviour as member statics.
Member statics are only initialised if the program control flow passes
their declaration. If the control flow never executes the declaration,
then the static is never instantiated.
Previously, global/namespace statics had similar behaviour - they were
only initialised if code in the enclosing translation unit was executed.
This is no longer the case. Global/namespace statics now appear to be
instantiated regardless of whether code in the enclosing translation
unit is used.
This may increase the memory footprint for applications that have
global/namespace statics in translation units containing code that may
be conditionally executed. In some cases (such as PTLib) this may lead
to different behaviour.
In the case of PTLib (disclaimer: I am the co-author and co-maintainer)
we can work around this issue using the "initialise on first use"
paradigm. But it may be that other application maintainers will not be
so fortunate to have the zealous co-maintainers that tracked down this
issue for us.
Of course, I expect that most application won't notice the difference,
other than perhaps some slight increase in runtime memory usage,
Craig
--
-----------------------------------------------------------------------
Craig Southeren Post Increment ñ VoIP Consulting and Software
craigs@postincrement.com.au www.postincrement.com.au
Phone: +61 243654666 ICQ: #86852844
Fax: +61 243656905 MSN:craig_southeren@hotmail.com
Mobile: +61 417231046 Jabber:craigs@jabber.org
"Science is the poetry of reality." Richard Dawkins
next reply other threads:[~2011-05-15 10:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-15 10:14 Craig Southeren [this message]
2011-05-16 0:15 ` Alan Modra
2011-05-16 0:37 ` Craig Southeren
-- strict thread matches above, loose matches on Subject: below --
2011-05-05 5:19 H.J. Lu
2011-05-05 8:27 ` Alan Modra
2011-05-05 13:27 ` H.J. Lu
2011-05-05 14:13 ` Alan Modra
2011-05-06 13:23 ` H.J. Lu
2011-05-06 16:16 ` H.J. Lu
2011-05-07 8:11 ` Alan Modra
2011-05-07 13:40 ` H.J. Lu
2011-05-07 14:05 ` Alan Modra
2011-05-09 13:53 ` Alan Modra
2011-05-09 14:09 ` H.J. Lu
2011-06-19 19:18 ` Thomas Schwinge
2011-06-21 15:14 ` Nick Clifton
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=4DCFA77B.9060300@postincrement.com \
--to=craigs@postincrement.com \
--cc=binutils@sourceware.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).