This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


 On Mon, May 9, 2011 at 6:53 AM, Alan Modra<>  wrote:
 >  I'm starting to wonder whether ld/testsuite/ld-elf/ 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 Southeren          Post Increment ñ VoIP Consulting and Software          

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905
 Mobile: +61 417231046

"Science is the poetry of reality." Richard Dawkins

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]