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

[Ingo Molnar <mingo@elte.hu>]

* Paolo Bonzini <pbonzini@redhat.com> 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