Re: PATCH: PR ld/12730: regression] crash when allocating in a static constructor

[Craig Southeren <craigs at postincrement dot com>]

------------------------------------------------------------------------

>  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