* Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 05/25/2011 12:17 PM, Ingo Molnar wrote: > > > Also it's not clear why ((constructor)) was written in the way it > > was: why apparently no access is given to the array of init > > functions > > It is accessible---glibc uses it. > > > and why it's not possible to turn the auto-execution off but > > still have the array generated, for legitimate cases that want to > > use data driven constructor execution. > > The compiler doesn't care about what is done with the data. It > simply provides the table for the runtime library to use it. > ((constructor)) is a veneer over the same infrastructure used for > C++ global constructors; that explains its design pretty well. Obviously the compiler did not provide this feature into a vacuum, it expected the C library to execute constructors, right? So the above dodges my question of why there is no method (in glibc) to turn auto-execution off and let the app do it. If all that was possible then ((constructor)) could certainly be used as a generalized shortcut for certain ((section)) uses. > > the ((section)) approach we could create a clear runtime BUG_ON() > > assert for a zero-sized array of init function pointers, > > Not really. The problem is that f1.o is not pulled from the static > library _because the linker thinks it is not necessary_. If f1.o > defines another symbol, and f.o uses it, then the constructor is > pulled in together with the rest of f.o. As soon as _one_ > constructor is pulled in (even from outside the static library), > your BUG() would not detect silently missing imports anymore. Yeah, good point. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
