[Bug ld/4538] add --all-init flag to force all static initializers to be loaded

[cnmnzusoib at mailinator dot com]

------- Additional Comments From cnmnzusoib at mailinator dot com  2007-08-07 
08:26 -------
> What advantage will --all-init bring you over --whole-archive?
All of the unreferenced units without static initializers can still be skipped.
I don't want to throw out the baby with the bath water.  Static archives 
provide performance advantages 
in size and link time by skipping unused units.  --whole-archive appears to 
eliminate most of the 
point of using an archive.
 
> How would you define --all-init in terms of the linker?  You are defining it 
> in
> terms of C++.  But different C++ implementations handle static constructors
> completely differently.  You need to define what --all-init should do in 
> linker
> terms.
I was thinking anything with a .init section or .ctors section, but I'm no 
expert at this.  Probing some of 
my binaries, looks like gcc emits a 
__static_initialization_and_destruction_0(int, int) in the .text which 
does the actual work, and if I understand how this goes together, the .ctors 
would then point to that 
function.  Is .ctors not the standard way that per-unit initializers are 
listed?  Ideally, this should also 
address __attribute__((constructor)) for C libraries, which share the same 
problem of not being called 
reliably.

So a naive implementation would link in everything with a non-zero .ctors (or 
.init/.dtors?)...
A slightly better solution might, for each unit, look at the symbols referenced 
in .ctors, recursively 
check the symbols referenced from those functions and build a list of external 
symbols.  Then, during 
final linkage, bring in only the units whose initializers reference symbols 
already in use. (e.g. if classes 
register with a factory, but you don't use the factory, *then* you can skip the 
whole bunch)

Is that in the right ball park?

> Quite aside from that, this is not a bug.  I recommend that you define what 
> the
> linker should do [...]
I would say it shouldn't change the runtime behavior based on whether you 
linked via an archive or via 
individual object files.  Optimizations are well and good, as long as they 
don't change the runtime 
results.  I call that a bug.  But if you want to call it 'pedantic' and call it 
a feature request instead, fine, 
whatever, I already tried to meet you halfway on that.

> [...] write a patch, and send it to the mailing list to see what
> people think.
Are those people going to reply "Not a bug" and ignore the patch without 
considering discussion or 
understanding what it's trying to do?  I'm sure as hell not motivated to invest 
hours of my time to get 
up to speed in the code base and try to bang something out if Mr. Modra's just 
going to kick-ban me at 
the end for suggesting binutils isn't perfect.  That kind of attitude is going 
to do nothing for bringing in 
contributors, and neither is closing the bugzilla entries for their feature 
requests. (How do you listen to 
users requests?  Oh, apparently you don't.  Thanks.)

> Please don't keep reopening this bug.  That is inappropriate behaviour.
Please don't keep closing the bug without addressing it.  *That* is 
inappropriate behavior.  I'm happy to 
leave it closed if it turns out there's no way to implement this, or doing so 
is a bad idea.  If you won't 
even keep it open for consideration, what hope is there for someone making a 
patch?  You're essentially 
shooting down the entire concept, so no one's going to waste their time on 
something you've 
preemptively dismissed.

Anyway, at least you addressed it, so I'll leave it closed.  But if anyone else 
thinks this is being given 
short shrift, feel free to chime in.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=4538

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.