------- 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
