Re: [PATCH 5/5 V2] kvm tools: Initialize and use VESA and VNC

Paolo Bonzini
2011-05-25T10:44:37Z

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