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 10:32 AM, Ingo Molnar wrote:
> >
> >* Paolo Bonzini<pbonzini@redhat.com>  wrote:
> >
> >>>   In that sense ((section)) is way more robust: there's not really that many
> >>>   ways to screw that up. Fiddling with the ((constructor)) environment on the
> >>>   other hand ...
> >>
> >> Sorry, this is textbook FUD.
> >
> > I specifically cited the problem of static libraries. They *do 
> > not work* with ((constructor)).
> 
> ((constructor)) has easily explained semantics: it's the same 
> semantics as C++ global constructors.  If you don't like those, 
> that's another story.

It is a plain *bug* if device initialization is not being executed if 
kvm is linked into a static library using the regular way of how 
libraries are created ...

No amount of arguing about 'semantics' will change that simple fact: 
it breaks code so it's a bug. We don't want to rely on a facility 
that handles boundary conditions in such a poor way.

See my prior point:

 - Also, over the years i have grown to be suspicious of GCC defined
   extensions. More often than not the GCC project is fixing regressions not by
   fixing the compiler but by changing the documentation ;-) We got bitten by
   regressions in asm() behavior in the kernel rather often.

   In that sense ((section)) is way more robust: there's not really that many
   ways to screw that up. Fiddling with the ((constructor)) environment on the
   other hand ...

You are demonstrating this phenomenon rather well. You argue against 
plain old bugs with 'but these are well-defined semantics'.

That's not how we deal with bugs in tools/kvm/ really.

And then you argue that the bug can be worked around by writing a 
linker script:

 > compilation with static libraries:
 >       $ gcc f.c -o f.o -c
 >       $ gcc f1.c -o f1.o -c
 >       $ ar cr f1.a f1.o
 >       $ ld -r f.ld f.o f1.a -o f2.o
 >       $ gcc f2.o -o a.out
 >       $ ./a.out
 >       12345678

I will rather use linker scripts and less erratic facilities straight 
away.

Thanks,

	Ingo