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.
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.
It turns out a way to get the semantics you want for ((section)) is to use --whole-archive (and possibly --no-whole-archive) on the "ld -r" command line. You can do the same on the link line for ((constructor)) or C++ constructors too. However, since you're effectively using a C++ feature, static libraries are probably a bad idea just like C++ static libraries are.
Paolo -- 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
