* Paolo Bonzini <[email protected]> wrote:
> On 05/25/2011 10:32 AM, Ingo Molnar wrote:
> >
> >* Paolo Bonzini<[email protected]> 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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
