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

[Paolo Bonzini <pbonzini@redhat.com>]

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