[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/4538] add --all-init flag to force all static initializers to be
cnmnzusoib at mailinator dot com
[Bug ld/4538] add --all-init flag to force all static initializers to be loaded
7 Aug 2007 08:26:04 -0000
------- Additional Comments From cnmnzusoib at mailinator dot com 2007-08-07
> 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
> terms of C++. But different C++ implementations handle static constructors
> completely differently. You need to define what --all-init should do in
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
So a naive implementation would link in everything with a non-zero .ctors (or
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
Is that in the right ball park?
> Quite aside from that, this is not a bug. I recommend that you define what
> 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
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.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.